RE: Uplifiting to glibc 2.3.2

> After reading it some times over I think that the LSB manner 
> of using chroot
> is better than the LFS manner. This because it really can be 
> reduced to what
> is actually needed for a minimal LSB implementation. However, 
> the LFS manner
> is much more flexible and, as I understand, simpler to deal 
> with. It really comes down to this:
> 
> If you want to spend lot's of time configuring the newer 
> libraries which are actually revamped when making a dynamic
> version of it, or if you want to speed up things.
> 
> At the end, it can be exactly the same system (both using the 
> LSB or the LFS manner). I suggest that you first try to use
> the LSB manner, because of compatibility issues, but if it is
> really to expensive (in measures of time), switch to the LFS manner.

Thanks for the comments.

I did work out what I had to do - this time - to defeat
glib's configure.  There are two configured variables
that can be assigned the correct values so that configure
doesn't test for them (it's essentially behaving like
those values were cached). In addition, I have to create
one empty header file <limits.h> or inclusion will fail
in another test that I can't eliminate.

And once glibc is built at the start of the intermediate
phase, then of course after that its' headers will be
installed and this type of problem goes away.  I wonder
if the bootstrap compiler ought to be treated as a
cross-compiler and if that would avoid glibc's configure
expecting glibc to already be installed... someone put
some special stuff in the build of gcc to make sure it
is not and there was probably a reason for that, I guess.

Mats