[Bug driver/46516] gfortran-trunk: error: libgfortran.spec: No such file or directory

["burnus at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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.