Build Glibc Twice (was Re: Decision on the Glibc hack issue)

Ryan.Oliver at Ryan.Oliver at
Sun Jan 5 22:24:28 PST 2003

Greetings all (and happy new year)

Apologies for posting on a week old thread, just got back from holidays...

On December 31, 2002, 08:04 AM Gerard Beekmans wrote:
> Btw I wil put a second Glibc installation in the book today. But Glibc
> chapter's less pure in my eyes. The less installed in chapter 5
> better in my eyes.
> I must say this: quality means more to me than purity. If there are
> technical grounds that Glibc in chap5 (plus a reinstall at the end of
> or whereever) achieves a higher technical quality then I'll of course go
> for it in a heartbeat.

If its built during chapter 5 you can use bind mounts to overlay glibc over
the chrooted filesystem ( ie /lib /usr/lib /usr/include ) just before the
chapter 6 glibc configure. Configure will then be happy and avoid most all
of the issues explained by Greg Schafers great posts.
Just before the "make install" umount them. Whats left is a pristine glibc,
avoiding quite a few hacks.

The build order I have been using is (ch 5)
 - binutils
 - gcc-3.2.x (as required by glibc-2.3.x) with --with-as= and --with-ld=
bind mount $LFS/static to /static
ensure /static/bin is first in PATH
 - kernel headers ( installed under /static/usr/include )
 - glibc ( prefix set to /usr, --with-binutils=/static/bin, installed under
   $LFS/static )
 - everything else

The other reason for doing it first is that I have been toying with linking
everything in chapter 5 statically against the new libc.a (with mixed
success, bash has blown out to 6Mb in size :-/ but is fully functional),
thus avoiding any nss issues and reducing the number of patches ( the fewer
mods to glibc the better as far as I'm concerned ).


Unsubscribe: send email to listar at
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list