Hi, Goswin von Brederlow wrote: > On Sun, Jul 22, 2012 at 12:52:10PM -0500, Jonathan Nieder wrote:
>> a) Help upstream authors of toolchain components with hardcoded >> header and library search paths to implement multiarch. [...] > What I don't understand is why compilers (which probably means ld from > binutils in all cases) won't use ld.so.conf to find the libs. It only > does so to find libs linked into libs you link against. So it is used > execpt for the verry first level of recursion. The ld library path and compiler library path represent different things[*]. [..] > Maybe this could be fixed > better in a single common point. Something like "getconf CPATH" and "getconf LIBRARY_PATH" producing approprite lists for passing to -I and -L to find the system libs and headers without having to parse "gcc -print-search-dirs" output could be interesting. Is that what you mean? [...] > I find it a bit hard to believe CPATH is needed. That directory has > been in use for years and years way before multiarch. >From the bug log: | Bug#637218 is a similar problem about headers moving. Have you tried it and run into different results? >> c) Compatibility wrapper. If someone needs this, feel free to email >> me and I'll help out however I can. > > If you write one of those then please make sure it works with gcc, gcc > -m32, gcc -m64 and uclibc [...] Let's not get ahead of ourselves. I'm not aware of a wrapper having been written, and I certainly wouldn't want to impose additional requirements on someone trying unless someone interested is providing the patches to support those. Hope that helps, Jonathan [*] - One is looking for libfoo.so.5, the other for libfoo.so and libfoo.a. - One points to libs on the arch with running binaries, while the other has libs for the cross-compilation target. - One contains /lib, the other doesn't. - One should not contain compiler-specific directories like /usr/lib/gcc/i486-linux-gnu/4.6, while the other does. - One can be manipulated for special-case tricks with LD_LIBRARY_PATH, the other with LIBRARY_PATH. Declaring that the compiler library path always include the ld library path would not take care of cross-compilation anyway, so my first reaction is to suspect it wouldn't be worth the side-effects. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120723114458.GC14294@burratino
