Summary: | Linking against system libs although the corresponding libs exist in $EPREFIX | ||
---|---|---|---|
Product: | Gentoo/Alt | Reporter: | Stefan Hoelldampf <stefan.hoelldampf> |
Component: | Prefix Support | Assignee: | Gentoo Prefix <prefix> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | lil_tux |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | patch potentially fixing this issue |
Description
Stefan Hoelldampf
2009-03-11 20:48:52 UTC
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. |