On Mon, Jul 08, 2013 at 08:11:03AM -0700, Bruce Korb wrote:
> > But having multilib enabled by default on x86_64 is simply very highly
> > desirable,
> 
> REMEMBER: we are talking about having a multilib enableable test in
> the configure.  If it fails, then it is not enabled by default.  This is not
> rocket science.
It isn't that trivial though, would you do this for native linux
configurations only (or how would you handle crosses?), what about
--with-sysroot configurations where the system compiler might e.g. not
support sysroots, what if the system compiler isn't gcc, or what if it is
gcc, but doesn't support multilibs, yet the newly built gcc would be capable
of supporting that?
So maybe for native configuration without --with-sysroot if system compiler
is gcc and a configure test can be compiled successfully when not using
any headers with a non-primary multilib option, but a test including some
well known glibc header like stdlib.h would fail with an error, error out
(silently disabling multilibs would look wrong to me, given that it
would be a very problematic heuristics only working sometimes).
But, the next question is how to find out what multilib options to pass,
if system compiler is gcc, it can check --print-multilib and derive that
info from it, but do you have a guarantee that the system gcc multilib
support matches the to be built compiler's multilib (e.g., you can have
system gcc built on ppc* to default to -m32 and have -m64 as non-default
multilib option and configure new gcc to do it the other way around, etc.).
Do you still think it is that trivial?

Far easier would be if not inhibit_libc to try to compile some trivial
program using say stdlib.h include in libgcc configure and error out there,
if it isn't for the primary multilib hint that either development support
for the non-primary multilib needs to be installed or --disable-multilib
used in configure.  That would have the disadvantage that the error would
show up only after at least first stage of gcc has been built, but would be
more reliable.

        Jakub

Reply via email to