http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46516
--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-11-17
08:20:07 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > I suppose it's the --disable-multilib, but I don't know why.
>
> Yes, it is certainly this. The driver seems to search only in the lib
> directory
> and not in the lib64 directory. If I copy the spec file from lib64 to lib it
> works.
What's the content of the $BUILD/gcc/multilib.h file? In particular the
multilib_raw one? Here, it is (x86-64-linux with multilib):
static const char *const multilib_raw[] = {
". !m64 !m32;",
"64:../lib64 m64 !m32;",
"32:../lib !m64 m32;",
NULL
};
I fear that the current multilib support assumes that the path only has a
suffix if one has multilib enabled; cf. gcc.c's for_each_path which is called
by find_a_file. It seems to search without multilib in, e.g.
/usr/lib
and with multilib in
/usr/lib/../lib64 for -m64
/usr/lib/../lib for -m32
/usr/lib/. for neither -m32 nor -m64 (does this ever happen?)
I think that was a good assumption before the 64bit support on x86-64 was
added; there, old programs (with /usr/lib) should continue to work thus the
64bit libs where placed at a non-default directory: /usr/lib64.
(For all above: Analogously for "/usr/local/lib" and $PREFIX/lib etc.)
Hence, I am interested how a --disable-multilib $BUILD/gcc/multilib.h looks
like.
