Bug#637232: Multiarch breaks support for non-multiarch toolchain
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
> 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,
- One is looking for libfoo.so.5, the other for libfoo.so and
- 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.