Today I have bootstrapped and upgraded a Prefix on amd64-linux (RHEL4). Somehow system libs seem to be used although these libs also exist in $EPREFIX. One example is sys-apps/dbus, but there are a lot of others. The leading /usr/lib64 RPATH is quite suspicious. $ echo $EPREFIX /tmp/gentoo $ ldd $EPREFIX/usr/bin/dbus-daemon libexpat.so.0 => /usr/lib64/libexpat.so.0 (0x0000002a9566c000) libc.so.6 => /lib64/tls/libc.so.6 (0x0000002a957bb000) /lib64/ld-linux-x86-64.so.2 (0x0000002a95556000) $ readelf --dynamic $EPREFIX/usr/bin/dbus-daemon Dynamic section at offset 0x57d00 contains 23 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libexpat.so.0] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x000000000000000f (RPATH) Library rpath: [/usr/lib64:/tmp/gentoo/usr/x86_64-pc-linux-gnu/lib/gcc:/tmp/gentoo/usr/x86_64-pc-linux-gnu/lib:/tmp/gentoo/usr/lib:/tmp/gentoo/lib] 0x000000000000000c (INIT) 0x12a78 0x000000000000000d (FINI) 0x44988 0x0000000000000004 (HASH) 0x220 0x0000000000000005 (STRTAB) 0x9278 0x0000000000000006 (SYMTAB) 0x2498 0x000000000000000a (STRSZ) 29389 (bytes) 0x000000000000000b (SYMENT) 24 (bytes) 0x0000000000000015 (DEBUG) 0x0 0x0000000000000003 (PLTGOT) 0x257fe8 0x0000000000000002 (PLTRELSZ) 2448 (bytes) 0x0000000000000014 (PLTREL) RELA 0x0000000000000017 (JMPREL) 0x120e8 0x0000000000000007 (RELA) 0x10ea0 0x0000000000000008 (RELASZ) 4680 (bytes) 0x0000000000000009 (RELAENT) 24 (bytes) 0x000000006ffffffe (VERNEED) 0x10e70 0x000000006fffffff (VERNEEDNUM) 1 0x000000006ffffff0 (VERSYM) 0x10546 0x000000006ffffff9 (RELACOUNT) 184 0x0000000000000000 (NULL) 0x0 $ find $EPREFIX -name libexpat.so\* /tmp/gentoo/usr/lib/libexpat.so /tmp/gentoo/usr/lib/libexpat.so.1 /tmp/gentoo/usr/lib/libexpat.so.1.5.2
The problem seems to be in the multilib/non-multilib amd64 area again: "gcc -print-search-dirs" returns the following paths in the library section: /tmp/gentoo/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/ /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/ /tmp/gentoo/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../x86_64-pc-linux-gnu/lib/x86_64-pc-linux-gnu/4.2.4/ /tmp/gentoo/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../x86_64-pc-linux-gnu/lib/../lib64/ /tmp/gentoo/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../x86_64-pc-linux-gnu/4.2.4/ /tmp/gentoo/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../lib64/ /lib/x86_64-pc-linux-gnu/4.2.4/ /lib/../lib64/ /usr/lib/x86_64-pc-linux-gnu/4.2.4/ /usr/lib/../lib64/ /tmp/gentoo/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../x86_64-pc-linux-gnu/lib/ /tmp/gentoo/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../ /lib/ /usr/lib/ gcc tries to use the non-existing "lib64" within $EPREFIX (/tmp/gentoo) thus only the following paths are considered: /tmp/gentoo/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4 /lib64 /usr/lib64 /tmp/gentoo/usr/x86_64-pc-linux-gnu/lib /tmp/gentoo/usr/lib /lib /usr/lib These paths are eventually used by libtool which is created during the configure run of sys-apps/dbus.
% gcc -print-search-dirs | grep libraries | sed -e 's/:/\n/g' | sed -e "s|${EPREFIX}|EPREFIX|g" libraries =EPREFIX/usr/lib/gcc/x86_64-pc-solaris2.11/4.2.4/ /usr/lib/gcc/x86_64-pc-solaris2.11/4.2.4/ EPREFIX/usr/lib/gcc/x86_64-pc-solaris2.11/4.2.4/../../../../x86_64-pc-solaris2.11/lib/x86_64-pc-solaris2.11/4.2.4/ EPREFIX/usr/lib/gcc/x86_64-pc-solaris2.11/4.2.4/../../../../x86_64-pc-solaris2.11/lib/amd64/ EPREFIX/usr/lib/gcc/x86_64-pc-solaris2.11/4.2.4/../../../x86_64-pc-solaris2.11/4.2.4/ EPREFIX/usr/lib/gcc/x86_64-pc-solaris2.11/4.2.4/../../../amd64/ /lib/x86_64-pc-solaris2.11/4.2.4/ /lib/amd64/ /usr/lib/x86_64-pc-solaris2.11/4.2.4/ /usr/lib/amd64/ EPREFIX/usr/lib/gcc/x86_64-pc-solaris2.11/4.2.4/../../../../x86_64-pc-solaris2.11/lib/ EPREFIX/usr/lib/gcc/x86_64-pc-solaris2.11/4.2.4/../../../ /lib/ /usr/lib/
(that means: same crap for Solaris)
intersting observation: =/lib/powerpc-apple-darwin8/4.2.1/ /lib/ /usr/lib/powerpc-apple-darwin8/4.2.1/ /usr/lib/ EPREFIX/usr/lib/gcc/powerpc-apple-darwin8/4.2.1/ /usr/lib/gcc/powerpc-apple-darwin8/4.2.1/ EPREFIX/usr/lib/gcc/powerpc-apple-darwin8/4.2.1/../../../../powerpc-apple-darwin8/lib/powerpc-apple-darwin8/4.2.1/ EPREFIX/usr/lib/gcc/powerpc-apple-darwin8/4.2.1/../../../../powerpc-apple-darwin8/lib/ EPREFIX/usr/lib/gcc/powerpc-apple-darwin8/4.2.1/../../../powerpc-apple-darwin8/4.2.1/ EPREFIX/usr/lib/gcc/powerpc-apple-darwin8/4.2.1/../../../ this is a nightmare, if it would be the actual library search path order, however: % ld -v @(#)PROGRAM:ld PROJECT:ld64-85.2.1 Library search paths: /Library/Gentoo/usr/powerpc-apple-darwin8/lib/gcc /Library/Gentoo/usr/powerpc-apple-darwin8/lib /Library/Gentoo/usr/lib /Library/Gentoo/lib /usr/lib /usr/local/lib Framework search paths: /Library/Frameworks/ /System/Library/Frameworks/ ld warning: -arch not specified ld: no object files specified for inferred architecture ppc which is the reason why it works well on Darwin, however, it still doesn't look healthy what gcc has in mind.
please try this and report the output: echo "int main() {}" > t.c gcc -c -o t.o t.c libtool --tag=CC --mode=link gcc -lltdl -o t t.o I believe this is the root of the problem. On Solaris this results in: libtool: link: gcc -o t t.o <PREFIX>/usr/lib/libltdl.so -Wl,-rpath -Wl,<PREFIX>/usr/lib -Wl,-rpath -Wl,<PREFIX>/usr/lib but on Darwin, it results in: glibtool: link: gcc -o t t.o /usr/lib/libltdl.3.1.0.dylib -ldl and on Linux it is reported to do it wrong as well.
As expected: $ echo "int main() {}" > t.c $ gcc -c -o t.o t.c $ libtool --tag=CC --mode=link gcc -lltdl -o t t.o libtool: link: gcc -o t t.o /usr/lib64/libltdl.so -ldl -Wl,-rpath -Wl,/usr/lib64 -Wl,-rpath -Wl,/usr/lib64
Umm well, at least on darwin libtool's search path is somewhat less healthy: $ grep search_path_spec /Gentoo/usr/bin/*libtool /Gentoo/usr/bin/glibtool:sys_lib_search_path_spec="/usr/lib/i686-apple-darwin9/4.2.1 /usr/lib /Gentoo/usr/lib/gcc/i686-apple-darwin9/4.2.1 /usr/lib/gcc/i686-apple-darwin9/4.2.1 /Gentoo/usr/i686-apple-darwin9/lib /Gentoo/usr/lib /usr/local/lib" /Gentoo/usr/bin/glibtool:sys_lib_dlsearch_path_spec="/usr/local/lib /lib /usr/lib" What i can tell from the script itself: Executable linkage uses: searchdirs="$newlib_search_path $lib_search_path $sys_lib_search_path $shlib_search_path" Unless you specify additional -L arguments, the first variables are empty and $lib_search_path contains $sys_lib_search_path_spec, thus libtool searches in the following for loop the path from above and finds its lib in /usr/lib first. This is going to happen for every lib, that's not found in -L arguments. When using sys_lib_search_path_spec="/Gentoo/usr/lib/gcc/i686-apple-darwin9/4.2.1 /usr/lib/gcc/i686-apple-darwin9/4.2.1 /Gentoo/usr/i686-apple-darwin9/lib /Gentoo/usr/lib" and sys_lib_dlsearch_path_spec="/Gentoo/lib /Gentoo/usr/lib" the following happens on darwin: $ echo "int main() {}" > t.c $ gcc -c -o t.o t.c $ libtool --tag=CC --mode=link gcc -lltdl -o t t.o glibtool: link: gcc -o t t.o /Gentoo/usr/lib/libltdl.dylib $ otool -L t t: /Gentoo/usr/lib/libltdl.7.dylib (compatibility version 10.0.0, current version 10.0.0) /Gentoo/usr/lib/gcc/i686-apple-darwin9/4.2.1/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.3) So i'd love to have some sanitizing patching there ;)
hm. i darkly remember libtool containing some code to ask gcc about search paths and ignore search_path_sepcs -> so be carefull :)
(In reply to comment #8) > hm. i darkly remember libtool containing some code to ask gcc about search > paths and ignore search_path_sepcs -> so be carefull :) > Well, I didn't say it's *the* solution. But it should lessen the problems a bit. One still can construct worst-case scenarios like calls to the wrong libtool, false arguments to libtool. Wat I'm trying to say is, that we can't find one solution to fit all aspects, but we can put pieces together ;) Anyway, any chance of getting you to remember where/when it asks gcc for paths? Do you by chance refer to compiler_lib_search_dirs?
Created attachment 186988 [details, diff] patch potentially fixing this issue While reemerging gcc-3.4.6 on AIX I've seen la-files containing wrong libdirs. Additionally, while building gcc, emake gets called with 'LIBPATH=${LIBPATH}", which does not contain $EPREFIX. The wrong libdirs in la-files are caused by merging upstream bug#125728 in changeset 37470, but the 'emake LIBPATH' bit is much older...
This is a mega-old bug and seems "fixed" to me. Given the example in Comment #0: (In reply to comment #0) > $ ldd $EPREFIX/usr/bin/dbus-daemon > libexpat.so.0 => /usr/lib64/libexpat.so.0 (0x0000002a9566c000) > libc.so.6 => /lib64/tls/libc.so.6 (0x0000002a957bb000) > /lib64/ld-linux-x86-64.so.2 (0x0000002a95556000) %% ldd $EPREFIX/usr/bin/dbus-daemon libexpat.so.1 => /home/jolexa/portage/linux-64/usr/lib/libexpat.so.1 (0x0000002a9566c000) libpthread.so.0 => /lib64/tls/libpthread.so.0 (0x0000002a958c8000) libc.so.6 => /lib64/tls/libc.so.6 (0x0000002a959dd000) /lib64/ld-linux-x86-64.so.2 (0x0000002a95556000)
wrt haubi's patch, it seems that one got applied, or at least the current state of the eclass prefixes all occurrences of LIBPATH. Closing.
