Bug#637232: Multiarch breaks support for non-multiarch toolchain

[Jonathan Nieder <jrnieder@gmail.com>]

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.