From glibc-2.2.x to glibc-2.3.x

mclinden at mclinden at
Wed Oct 30 08:16:39 PST 2002

> But I don't particularly like the idea of 
> having to do chapter 6 (partially) twice.

I initially switched to LFS from RedHat in order to create a reasonable 
platform for Oracle deployments that was not top-heavy with irrelevant 
goodies. The straw that broke the camel's back for me was when one of the 
RedHat releases came with a build of gcc which came from an experimental 
branch and was not compatible with anything. 

Although this is theoretically BLFS and not LFS, the reality is that LFS 
is base platform for a lot of practical custom systems, some of which do 
quite well in production settings and are highly competitive with 
commercial Linux distributions. There is often a high penalty to be paid 
for being too cutting edge (witness the number of larger systems that 
have/had difficulty being compiled with automake versions greater than 1.5 
or gcc3.0 instead of 3.1).

So I guess what I am trying to say (without adding noise to the system) is 
that when the choice is between stability and cutting edge performance, we 
consider erring on the side of stability. That is to say, if LFS is to be 
more than just a platform for experimenting with Linux configurations and 
is, instead, a platform for controlled Linux deployments, requiring 
patches to the core elements of the compiler or the C library that are 
inconsistent with the stable branches of these is a slippery slope we may 
want to avoid.


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