Had to ln -s /usr/lib/gcc/i386-pc-linux-gnu/3.4.4/libstdc++.so /usr/lib, because the enchant configure gets the path wrong, and only looks in /usr/lib. I had just upgraded to gcc 3.4.4 when I ran into this. I had compiled enchant under gcc 3.3.6 before. People will run into this during their 'emerge -e world' during the gcc upgrade, if they had enchant emerged before. Reproducible: Always Steps to Reproduce: 1.emerge enchant 1.1.6 or 1.2.0 2. 3. Actual Results: /bin/sh ../../libtool --mode=link --tag=CXX i386-pc-linux-gnu-g++ -O2 - mcpu=pentium3 -fomit-frame-pointer -o libenchant_ispell.la -rpath /usr/lib/ enchant -version-info 3:0:2 -no-undefined correct.lo good.lo hash.lo ispell_checker.lo lookup.lo makedent.lo tgood.lo -Wl,--export-dynamic -lgmodule- 2.0 -ldl -lglib-2.0 ../../src/libenchant.la libtool: link: warning: `/usr/lib/gcc/i386-pc-linux-gnu/3.4.4/../../..// libgmodule-2.0.la' seems to be moved i386-pc-linux-gnu-g++ -shared -nostdlib /usr/lib/gcc/i386-pc-linux-gnu/3.4.4/.. /../../crti.o /usr/lib/gcc/i386-pc-linux-gnu/3.4.4/crtbeginS.o .libs/correct.o .libs/good.o .libs/hash.o .libs/ispell_checker.o .libs/lookup.o .libs/ makedent.o .libs/tgood.o -Wl,--rpath -Wl,/var/tmp/portage/enchant-1.2.0/work/ enchant-1.2.0/src/.libs -L/usr/i386-pc-linux-gnu/lib -L/usr/i386-pc-linux-gnu/ bin -L/usr/lib/gcc/i386-pc-linux-gnu/3.4.4/../../../ -L/usr/lib /usr/lib/ libgmodule-2.0.so -ldl /usr/lib/libglib-2.0.so ../../src/.libs/libenchant.so -L/ usr/lib/gcc/i386-pc-linux-gnu/3.4.4 -L/usr/lib/gcc/i386-pc-linux-gnu/3.4.4/../.. /../../i386-pc-linux-gnu/lib -L/usr/lib/gcc/i386-pc-linux-gnu/3.4.4/../../.. / usr/lib/libstdc++.so -lm -lc -lgcc_s /usr/lib/gcc/i386-pc-linux-gnu/3.4.4/ crtendS.o /usr/lib/gcc/i386-pc-linux-gnu/3.4.4/../../../crtn.o -mcpu=pentium3 - Wl,--export-dynamic -Wl,-soname -Wl,libenchant_ispell.so.1 -o .libs/ libenchant_ispell.so.1.2.0 i386-pc-linux-gnu-g++: /usr/lib/libstdc++.so: No such file or directory make[2]: *** [libenchant_ispell.la] Error 1 make[2]: Leaving directory `/var/tmp/portage/enchant-1.2.0/work/enchant-1.2.0/ src/ispell' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/enchant-1.2.0/work/enchant-1.2.0/ src' make: *** [all-recursive] Error 1 Expected Results: /bin/sh ../../libtool --mode=link --tag=CXX i386-pc-linux-gnu-g++ -O2 - mcpu=pentium3 -fomit-frame-pointer -o libenchant_ispell.la -rpath /usr/lib/ enchant -version-info 3:0:2 -no-undefined correct.lo good.lo hash.lo ispell_checker.lo lookup.lo makedent.lo tgood.lo -Wl,--export-dynamic -lgmodule- 2.0 -ldl -lglib-2.0 ../../src/libenchant.la libtool: link: warning: `/usr/lib/gcc/i386-pc-linux-gnu/3.4.4/../../..// libgmodule-2.0.la' seems to be moved i386-pc-linux-gnu-g++ -shared -nostdlib /usr/lib/gcc/i386-pc-linux-gnu/3.4.4/.. /../../crti.o /usr/lib/gcc/i386-pc-linux-gnu/3.4.4/crtbeginS.o .libs/correct.o .libs/good.o .libs/hash.o .libs/ispell_checker.o .libs/lookup.o .libs/ makedent.o .libs/tgood.o -Wl,--rpath -Wl,/var/tmp/portage/enchant-1.2.0/work/ enchant-1.2.0/src/.libs -L/usr/i386-pc-linux-gnu/lib -L/usr/i386-pc-linux-gnu/ bin -L/usr/lib/gcc/i386-pc-linux-gnu/3.4.4/../../../ -L/usr/lib /usr/lib/ libgmodule-2.0.so -ldl /usr/lib/libglib-2.0.so ../../src/.libs/libenchant.so -L/ usr/lib/gcc/i386-pc-linux-gnu/3.4.4 -L/usr/lib/gcc/i386-pc-linux-gnu/3.4.4/../.. /../../i386-pc-linux-gnu/lib -L/usr/lib/gcc/i386-pc-linux-gnu/3.4.4/../../.. / usr/lib/libstdc++.so -lm -lc -lgcc_s /usr/lib/gcc/i386-pc-linux-gnu/3.4.4/ crtendS.o /usr/lib/gcc/i386-pc-linux-gnu/3.4.4/../../../crtn.o -mcpu=pentium3 - Wl,--export-dynamic -Wl,-soname -Wl,libenchant_ispell.so.1 -o .libs/ libenchant_ispell.so.1.2.0 /usr/lib/gcc/i386-pc-linux-gnu/3.4.4/../../../../i386-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in object. (cd .libs && rm -f libenchant_ispell.so.1 && ln -s libenchant_ispell.so.1.2.0 libenchant_ispell.so.1) (cd .libs && rm -f libenchant_ispell.so && ln -s libenchant_ispell.so.1.2.0 libenchant_ispell.so) i386-pc-linux-gnu-ar cru .libs/libenchant_ispell.a correct.o good.o hash.o ispell_checker.o lookup.o makedent.o tgood.o i386-pc-linux-gnu-ranlib .libs/libenchant_ispell.a creating libenchant_ispell.la (cd .libs && rm -f libenchant_ispell.la && ln -s ../libenchant_ispell.la libenchant_ispell.la) make[2]: Leaving directory `/var/tmp/portage/enchant-1.2.0/work/enchant-1.2.0/ src/ispell' Enchant is the only package I've run into so far that seems to need this symlink. I was able to do 'emerge -e system' without it.
As far as I'm aware, that file should exist already. You sure gcc-config ran properly?
(In reply to comment #1) > As far as I'm aware, that file should exist already. You sure gcc-config ran > properly? When I upgraded gcc to 3.4.4, the gcc-config was already showing that it had automatically been switched. I believe I ran gcc-config again at the time. I also just toggled the gcc-config setting back and forth, and saw no change to the dates on the symlinks I created. I don't think this is something gcc-config changes. I removed the symlink and retried the enchant build, and it failed in the exact same way. The manually created symlink I created is needed to build it, or the lib configuration needs to find libstdc++.so as /usr/lib/gcc/i386-pc- linux-gnu/3.4.4/libstdc++.so and not as /usr/lib/libstdc++.so
I'd say remove the link and re-emerge GCC again. Make sure you rebuild everything (emerge -e world) and skip over failures (emerge --resume --skipfirst) if you run into them. Go back to them after that and try them again. Reopen if you still run into problems.
*** Bug 115332 has been marked as a duplicate of this bug. ***
I have run into this with libpcre and mysql (with more than 200 packages to go), and I have emerged gcc 3.4.4 four times. # gcc-config -l [1] i686-pc-linux-gnu-3.4.4 * [2] i686-pc-linux-gnu-3.4.4-hardened [3] i686-pc-linux-gnu-3.4.4-hardenednopie [4] i686-pc-linux-gnu-3.4.4-hardenednopiessp [5] i686-pc-linux-gnu-3.4.4-hardenednossp # gcc-config -c i686-pc-linux-gnu-3.4.4
(In reply to comment #5) > I have run into this with libpcre and mysql > (with more than 200 packages to go), and I > have emerged gcc 3.4.4 four times. I'm not surprised. I think it's a bug in a certain version or range of versions of the configure scripts. They get the path to that library wrong when run in the presence of gcc 3.4.4, but not with gcc 3.3.6. I haven't had time to look into enchant to find our how it's getting /usr/lib/gcc/i386-pc- linux-gnu/3.4.4/libstdc++.so turned into /usr/lib/libstdc++.so. I am suspicious of all the "../" components in its path. We have three examples. I am tempted to reopen this. I will if I find the bug.
Arts and aspell have also crashed with this problem (and I finally got to enchant, which did as well). > Make sure you rebuild everything (emerge -e world) > and skip over failures (emerge --resume --skipfirst) > if you run into them. Won't that cause problems if something built later links to something that didn't get rebuilt with gcc 3.3.4?
This (already a complete disaster) has become even more so. Fam wouldn't merge, and now kdelibs. I doubt anything that depends on kdelibs (quite a few things) will link properly with kdelibs unable to compile.
More programs that won't link: libusb imagemagick kdebase kdepim kdegames What reason do you have to think that these would possibly compile and link after emerge -e world finishes?
ignoring the fact your CHOST's are clearly screwed up (gcc-config shows i686 but linking shows i386), why dont you try re-emerging libtool and grepping for /usr/lib/libstdc++.so in /usr/lib/lib*.la and re-emerging those packages too
(In reply to comment #9) > More programs that won't link: ... > kdegames > > What reason do you have to think that > these would possibly compile and link > after emerge -e world finishes? They will for me, but only because I manually added the symlink mentioned in the first line of the description. It's still there, and I am not having any other problems. I am not following the plan to have me redo emerge -e world, because I know from the testing I described that it won't solve the problem. My plan, instead, is to find the root cause within the configure scripts for these packages, and post the real fix. This may take some time, so anyone else who wants to deep dive this thing is welcome to.
> ignoring the fact your CHOST's are clearly screwed > up (gcc-config shows i686 but linking shows i386), $ grep CHOST /etc/make.conf CHOST="i686-pc-linux-gnu" > why dont you try re-emerging libtool and grepping > for /usr/lib/libstdc++.so in /usr/lib/lib*.la and > re-emerging those packages too $ grep libstdc++.so /usr/lib/lib*la /usr/lib/libstdc++.la:dlname='libstdc++.so.5' /usr/lib/libstdc++.la:library_names='libstdc++.so.5.0.7 libstdc++.so.5 libstdc++.so' Doesn't look too helpful. :(
you shouldnt have a /usr/lib/libstdc++.la without a /usr/lib/libstdc++.so delete it
Add to the list of package suffering from this: dev-cpp/poslib-1.0.5
This is not a problem with the configure scripts or tons of people would be having the problem. You might as well list every single C++ package here, because they are all going to fail. Did you try doing as vapier suggested?
(In reply to comment #13) > you shouldnt have a /usr/lib/libstdc++.la without a /usr/lib/libstdc++.so > > delete it I renamed my symlink, and /usr/lib/libstdc++.la, and enchant now emerges. The la file was dated the same as the other libraries that were changed during the gcc upgrade process. It contains references to the 3.3.6 version of the library, which is now in /usr/lib/gcc-lib. After checking the create time of /usr/lib/libstdc++.la, and comparing with the times in /var/log/emerge.log, it turns out that it was created during the re- emerge of gcc-3.3.6 during the emerge -e system step of the gcc upgrade. This is probably leftover cruft or bad file handling in gcc-3.3.6. The la file should not have been created while gcc-config was pointing at gcc-3.4.4 libraries. Or, the gcc-upgrade directions should explicitely avoid emerging gcc- 3.3.6 again. The question now is: How did multiple calls to gcc-config, to switch to gcc 3.4. 4, manage to leave this file behind? It should have been deleted.
(In reply to comment #16) > (In reply to comment #13) > > you shouldnt have a /usr/lib/libstdc++.la without a /usr/lib/libstdc++.so > > > > delete it > > I renamed my symlink, and /usr/lib/libstdc++.la, and enchant now emerges. I still have problems, this time with app-office/koffice-libs. It complains about the missing .la file. The only work-around that works is having both the .la file and the .so symlink in place in /usr/lib.
Just to verify (before I get things screwed up even worse :) ), I have: # ls -al /usr/lib/libstdc++* -rwxr-xr-x 1 root root 262980 2005-07-25 22:13:19 /usr/lib/libstdc++-2-libc6.1- 1-2.9.0.so* -rwxr-xr-x 1 root root 334924 2005-07-25 22:13:19 /usr/lib/libstdc++-3-libc6.2- 2-2.10.0.so* lrwxrwxrwx 1 root root 30 2005-07-25 22:13:20 /usr/lib/libstdc++-libc6.1-1. so.2 -> libstdc++-2-libc6.1-1-2.9.0.so* lrwxrwxrwx 1 root root 31 2005-07-25 22:13:20 /usr/lib/libstdc++-libc6.2-2. so.3 -> libstdc++-3-libc6.2-2-2.10.0.so* -rw-r--r-- 1 root root 929 2005-12-07 01:31:01 /usr/lib/libstdc++.la lrwxrwxrwx 1 root root 20 2005-07-25 22:13:20 /usr/lib/libstdc++.so.2.7.2 - > libstdc++.so.2.7.2.8* -rwxr-xr-x 1 root root 226168 2005-07-25 22:13:19 /usr/lib/libstdc++.so.2.7.2. 8* lrwxrwxrwx 1 root root 18 2005-07-25 22:13:20 /usr/lib/libstdc++.so.2.8 -> libstdc++.so.2.8.0* -rwxr-xr-x 1 root root 255728 2005-07-25 22:13:19 /usr/lib/libstdc++.so.2.8.0* lrwxrwxrwx 1 root root 18 2005-07-25 22:13:20 /usr/lib/libstdc++.so.2.9 -> libstdc++.so.2.9.0* -rwxr-xr-x 1 root root 3772 2005-07-25 22:13:19 /usr/lib/libstdc++.so.2.9.0* /usr/lib/libstdc++-v3: total 752 drwxr-xr-x 2 root root 4096 2005-12-12 09:54:57 ./ drwxr-xr-x 54 root root 32768 2005-12-14 20:59:02 ../ lrwxrwxrwx 1 root root 18 2005-12-12 09:54:57 libstdc++.so.5 -> libstdc++. so.5.0.6* -rwxr-xr-x 1 root root 728120 2005-12-12 09:54:57 libstdc++.so.5.0.6* You say I should delete /usr/lib/libstdc++.la given these files, correct?
yes, and then if anything refers to '/usr/lib/libstdc++.la' in an .la file, just change it to '-lstdc++' or re-emerge the package
*** Bug 134957 has been marked as a duplicate of this bug. ***
