On Mon, Jul 8, 2013 at 8:24 AM, Jakub Jelinek <ja...@redhat.com> wrote: > 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.
Any solution other than an explanation-less "fatal error: gnu/stubs-32.h: No such file" is fine. There is no way to translate that message into "Either --disable-multilib or else install glibc 32 bit development" without coming up with the right Googling terms. I managed to futz around until I figured out the missing package. It was a day later that I found out it was all about multilib. Putting people through such a gauntlet just because you think a distro ought to have included glibc 32 bit development as part of a development package is not appropriate. So I see several choices. Primarily, assume that more often than not, builds are not cross builds, thus if multi-lib is not supported, likely the build will fail on the multilib part. Therefore, disable it _by default_. The user has to override, even if they are doing a cross build for a platform with multi-lib. The user alters the default if the host platform does not support it. But anything at all, as long as the way forward is explicit and does not involve Google.
