add --enable-languages flag to gcc instructions

coevolved_netbeast at coevolved_netbeast at
Sun Jun 8 06:08:48 PDT 2003

On 6 Jun 2003 at 18:07, Bill's LFS Login wrote:

> > Thus, while the book is written by Gerard, it's also a community effort
> > powered by the countless people interacting with it. Perhaps an analysis
> > of the people using it is in order to adjust some of the book's
> > assumptions.
> Casual assessments of that issue have led to the decisions I mentioned
> earlier. Further, there has been some discussion of various "guides",
> "tutorials", etc. But in all cases, the books intended audience has
> remained steady and the philosophy guiding what is in the book has also
> persevered. The "community effort" nature has been well acknowledged and
> included in the discussions that occurred in the past.

I agree with keeping the books intended 
audience.  I knew nothing about using linux 
before I embarked on LFS, it was a very steep 
learning curve and took me three attempts 
before I was satisfied with my system.
If the bar was lower, I'd know a lot less about 
linux than I do now.  If the book was 'LFS for 
Dummies', I'd still be posting to the lists 
everytime I tried to install something - fighting 
with an OS I don't understand.
Dumbing down the book will probably lead to 
more traffic on lfs-support in the long run.

Having said that, I think the LFS could be 
improved by little more detail for the flag and 
patch descriptions.
Simply stating that the nofixincludes patch for 
gcc prevents gcc from checking the include's, 
and that gcc fixes includes because different 
vendors sometimes use non-ANSI complient 
headers goes a long way to better learning, and 
increases confidence as to what the hell is 
going on when your following the book on blind 
Adding important flags like --enable-languages 
can only help educate, which is what I thought 
LFS was all about.
An appendix page, perhaps?

> > I find it significant that BLFS generates much less FAQ's
> > than LFS, while dealing with much more diverse material than LFS.
> > Regardless of the numerous other factors which contribute to that (like
> > a smaller reader base, the increased knowledge of it's readers wrt.LFS
> > etc.), a part of that is also because of the book's structure.
> The structure *sucks* if you are looking to, say install Gnome, and all
> you have is LFS and low-intermediate experience. It is not designed to
> get you point-a-to-point-b, as is LFS.
> I just finished a BLFS "end-to-end" (but for KDE, mozilla and
> a few other misc. items) install. BLFS *requires* a *lot* more
> expertise, a *lot* more reading, a *lot* more decision making, and
> therefore a *lot* more analysis of what you are doing. It addresses its
> intended audience by effectively saying "here's the jigsaw puzzle - call
> us when you have problems". There is no point-a-to-point-b. I think that
> presentation a) scares off most of those that lack the experience and b)
> tends to accrete those that have the needed personality traits to apply
> themselves effectively.

I learned enough from building LFS to compile 
Xfree(with a bit of help from the nice people on 
blfs-support to get it working), and install 
applications like xpdf, opera, etc.  In fact LFS 
has made me so familiar with linux, I have to 
smack myself in the head when I try to 'ls' or 
'rm' in a dos-box.
If someone doesn't understand linux enough to 
try a blfs project then LFS to them is just 
another distro they have to fight to use, they 
haven't learned anything from the book.
What might be of more help is references to 
package documentation, encourage people to 
read the documentation and work it out 
themselves.  I know that documentation can 
often be confusing and limited, but learning to 
cope with that is part of learning to use linux.

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