Bug#637232: Multiarch breaks support for non-multiarch toolchain
On Sun, Jul 22, 2012 at 12:52:10PM -0500, Jonathan Nieder wrote:
> affects 637232 + release-notes
> quit
>
> Hi,
>
> Matthias Klose wrote:
> > On 08/09/2011 07:31 PM, Aurelien Jarno wrote:
>
> >> I got fed up by people reporting bug on libc6, while this problem results
> >> from a decision Debian to implement multiarch. People should work on
> >> implementing a compatibility wrapper and to make upstream toolchain
> >> multiarch aware. Until this is done, this bug should be kept opened.
> >
> > just do it.
>
> To be realistic, is anyone actually going to do this?
>
> Avenues forward:
>
> a) Help upstream authors of toolchain components with hardcoded
> header and library search paths to implement multiarch.
>
> gcc: in progress - http://gcc.gnu.org/PR53468 (thanks, Matthias!)
> clang: fixed? - http://llvm.org/bugs/show_bug.cgi?id=6541
> icc (Intel C++): status?
> pathcc (PathScale ekopath): status?
> tcc (Tiny C compiler): fixed - b56edc7b, 2012-05-22
> pcc (Portable C compiler): unfixed - http://bugs.debian.org/638309
> cmake: fixed - http://public.kitware.com/Bug/view.php?id=12037
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. Maybe this could be fixed
better in a single common point.
> b) There is a workaround described in libc6/NEWS.Debian.gz which
> works fine:
>
> LIBRARY_PATH=/usr/lib/<triplet>
> CPATH=/usr/include/<triplet>
> export CPATH LIBRARY_PATH
>
> It's probably worth advertising that more widely, for example in
> the release notes.
I find it a bit hard to believe CPATH is needed. That directory has
been in use for years and years way before multiarch. Anyone know
which compiler needs it?
> 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 (which brings some wrappers already I
believe). It would also be nice to include i486-linux-gnu-* on amd64
and amd64-linux-gnu-* on i386 and similar for other archs.
MfG
Goswin
Reply to: