/usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory

[Brian Dessent]

Kamaraju S Kusumanchi wrote:

> Could some one please tell me what this package(s)' name is? I would like to
> ask the maintainer to install these packages. So it would be better if I
> know the required package(s)' names beforehand (instead of trial and
> error).

It's the glibc-devel package, i386 arch, so: yum install
glibc-devel.i386

> BTW, this looks pretty bad design decision on the gcc team's part. This kind
> of problem should have automatically been detected during the configuration
> stage itself. The configuration script went without any hiccups and problem
> surfaced only during the compilation stage....

That's a fair complaint I suppose.  But the plumbing of the build
machinery makes this a little hard to do I think.  The problem is that
multilibbing is controlled/orchestrated from the toplevel, and so the
choice to enable or disable it needs to be made there.  However, the
toplevel configure script doesn't really directly control the building
of any code, it just finds and selects tools and shuffles a bunch of
recursive configure and make options down to the subdirs.  The problem
occurs when building the 32 bit flavor of libgcc, which doesn't happen
until after the final stage 3 compiler is complete.  The libgcc
configure script would be in a position to detect if something is wrong,
but by that point it's far too late to do anything about it, as
everything has been setup by the toplevel for a multilib build.  The
best it could do would be to issue a more descriptive error, but an
error is currently exactly what you get, and it would not come at any
significantly earlier point in the build.

It's tempting to say just add a compile test for something trivial like
stdio.h with CC set to $(CC) -m32 to the toplevel configure.  But this
is an invalid test as well: it's testing a property of the bootstrap
compiler (which might not have been built to  be biarch, or might not
even be gcc at all) not testing for the presence of the required libc
headers.  However, the alternative of checking for the existance of
specific files is ugly and would never be accepted because it's
OS/target-specific, while toplevel is generic and shared across many
projects/targets.  The autoconf philosophy has always been function
tests (i.e. try to compile or link a sample), not trawling around in the
filesystem looking for the presence or absence of things.  But you can't
do a correct function test at toplevel; the place where you can do it is
libgcc configure which is too late in the process to be able to make any
changes, as explained previously.

Brian