Issues with LFS glibc-2.3.3 tarball

Ken Moffat ken at
Wed Feb 11 12:17:07 PST 2004

On Wed, 11 Feb 2004, Robert Connolly wrote:

> I'm reminded of an idea I had to separate the development tools from the
> system. For example, install chap5 to /stage1. In chap6 replace /usr with /
> tools. Install a tiny base (busybox) on /, development in /tools,
> applications stay in /usr and /opt. This is friendly to diskless and handheld
> systems that can mount tools and extra apps from network or storage cards.
> Might have uses on workstations too. For stability libc would need to be
> built twice, and if its anything like glibc, to use fpie and ssp properly, it
> would need to be built twice.
 Sounds interesting (particularly security aspects of minimising /usr on
a server, if I follow you).

> >  For the moment, it's a bit remote from LFS itself.
> I think its the same thing just with different software.
 I meant that you can't always build the applications (e.g. lynx
wouldn't build as of three months ago) - I see people using tiny X with
uClibc, but I've never been motivated to follow up on that, after all
once you put mozilla (not yet working properly with uClibc) or kde
there, libc's size is the least of your worries, and up to today uClibc
has only seriously been mentioned in a smaller-is-better context.

 The other difference is 'purity'.  If I understood one of Erik's posts
correctly the other week, you should build buildroot, then chroot into
it and rebuild the tools.  It's not _that_ different from the current
LFS method, but I suspect he won't look forward to another influx of
ex-LFS people if they start telling him his build method is suspect ;)

  At the end of the day, uClibc is a tool to get applicatins running
in minimal space.  The LFS projects are about learning.

Brighton tops UK Jedi league

More information about the hlfs-dev mailing list