Hardened LFS -GCC4

Kevin Day msu-kday at student.mcneese.edu
Fri Aug 19 18:52:40 PDT 2005

> While I would certainly like to see a move of LFS (and HLFS) toward GCC4 
> and would welcome the appropriate patches to make this happen, I would 
> urge a little caution in adopting GCC 4 (before GCC 4.1 is released) as 
> part of the mainstream for at least a couple of reasons.

This is a good idea as Hardened LFS itself will generate its own problems, if
we put too much "bleeding edge" on top of an experimental project, you are
looking for trouble. Not focusing on GCC-4 would allow other bugs to be weeded
out and not confused with GCC-4 bugs.

I believe that is whatsd being said here:

> First, "hardened" is typically inconsistent with bleeding edge insofar as 
> technology is concerned. I have identified at least a couple of problems 
> with GCC 4.0 (some of which have been fixed in the CVS) in compiling the 
> kernel and other code which cause me to be concerned that it is not, yet, 
> ready for production use insofar as hardened systems are concerned.

However, by the time this project gets out into a stable condition, GCC-4 will
be very stable (aside for unmaintained projects, which can be patched..).  So
it can be a good idea to have GCC-4 as a secondary compiler and make note of
any problems thereof.  But then, it may be easier to just save that for HLFS
version 2.0.

One final thing is that, with the continued introduction of open source to the
public, too many programmers have become "feature happy" and have been slowly
neglecting stability of bloated toys. (thus the rise of HLFS with the uclibc
split).  So for stability's purpose, I'd finally settle down to recommended
against it.  The turtle can beat the hare.

More information about the hlfs-dev mailing list