add --enable-languages flag to gcc instructions
coevolved_netbeast at softhome.net
coevolved_netbeast at softhome.net
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
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 linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message
More information about the lfs-dev