Uplifiting to glibc 2.3.2

Those of you who have watched the checking messages
know the lead-up to this, but I'll mention it anyway.

I'm taking a pass at uplifting a bunch of the lsbsi
packages for LSB 2.0, and while I'm there enabling
some additional architectures too.

The "simple" ones (one where we don't have an important
patch in place), and even a non-simple one (changing
to use coreutils, which is not quite done - I haven't
taken care of the "don't install non-LSB binaries"
part for it yet) are done.

gcc 3.2.x -> 3.3.2 didn't seem too big a deal, except
that there was a problem doing glibc 2.2.5 with it.
So it seemed the next step was to do glibc 2.2.5 ->
glibc 2.3.2.  This is proving a royal pain, because
the configure script (and the subsidiary config.guess)
do so much more. It's pretty much breaking the scheme
we use.

The current lsbsi scheme is to build a bootstrap,
consisting of a bunch of statically linked binaries.
The bootstrap is then copied to a chroot, and 
inside the chroot, a glibc and other libraries are
built, then everything is rebuilt dynamic (plus a
bunch of additional stuff, since the bootstrap is
really minimal).   The bootstrap does not include
glibc, since everything is statically linked it's
theoretically not needed.

The first thing built in the chroot is glibc, and
glibc 2.3.2 does a bunch of additonal configure
checks that 2.2.x didn't do, and these additional
checks depend on the presence of a bunch of headers
files that would normally be provided by glibc,
but are not present in the minimal copy-of-bootstrap
chroot, which never had glibc's headers installed
into it.  I've faked a couple of these, but it looks
like one of those "fix one, that lets you get to
turn over the next rock with nasty things under it"
deals.  I'm not sure I'm going to be able to solve
this reasonably.

The current Linux From Scratch does something
different. It still builds a first phase, but
it includes a full glibc, and it's not chrooted
to, it's simply in an alternate location, and doesn't
have the oddity we have of having to overwrite
everything that was built in the bootstrap phase,
as instead of chrooting to that tree, it uses
the binaries in the alternate location to build
the new tree.  To put this into lsbsi context,
we build bootstrap, chroot to it, and use that
to build the intermediate phase.  Then we use
the intermediate to build the final, reduced, phase.
LFS builds a bootstrap-like thing, changes paths
to use the bootstrap, and uses that to build
the intermediate phase.  Because LFS doesn't have
our requirement to produce a final limited phase,
that step is just skipped.

Okay, enough blather.  I'm interested in thoughts
about what I should do.  Continue to try to fake
it by adding empty or nearly-empty headers to the
intermediate-before-glibc phase until I get glibc-2.3.2
to configure correctly? or think about revamping the
first phase to align more closely with the current
LFS scheme?

-- mats