add --enable-languages flag to gcc instructions

Bill's LFS Login lfsbill at
Fri Jun 6 15:07:50 PDT 2003

On Fri, 6 Jun 2003, Jeroen Coumans wrote:

> Bill's LFS Login wrote:
> > On Fri, 6 Jun 2003, Jeroen Coumans wrote:
> >>Yes, this is becoming a bit of a FAQ [...]

> > *May be*. We all know that *some* folks can't ...]

> > Just wanted to highlight that judgement about problems of that sort are
> > needed [...]

> Maybe not just an analysis of the problem but also of the FAQ as an
> entity in and of itself; a collection of frequently encountered problems
> when dealing with LFS and the community. If the book is continuously and
> consistently disregarded or even ignored on certain aspects (like a
> really frequent one; #whynotversion), something is wrong with either the
> book's assumption about it's readers or it's logical presentation of the
> information.

I think the former (its audience) is the answer is likely the cause of
most of what we see that should not be seen. But we should avoid this
topic because the intended audience, and how to address the problem of
those who are not in the intended audience, has been thrashed rather
thoroughly in several past instances.

> Reasoning from the book's point of view, the FAQ's answers are not in
> the book because the book assumes it's readers follow it to the letter.

Ummm... not to be nit-picky, but I think the book presents what has been
well tested to increase the chance of success and does not assume the
user follows it to the letter. In fact, in various places, there is
verbiage about "have it your way" benefits. Certain things are not in
the book because the book needs to have some reasonable limits on
content, expects(?) a certain minimum level of expertise, and support
forums are provided for mistakes in command entry, wrong package use and
all other types of (un)expected errors. As to FAQ stuff not being there,
that seems to be a result of a combination of the items I just mentioned
and the availability of an excellent (IMO) FAQ maintainer and purpose of
the FAQ. I have seen "follow the book to the letter responses" only when
the judgement (apparently) of the responder was that the OP was delving
in areas where they might be over their head.

> It thus has a rigid structure: _any_ deviation, even something as
> trivial as a minor version number of a package, is a potential problem
> and certainly a FAQ. So reality (and lfs-support) shows us that this

I disagree that "_any_ deviation...certainly a FAQ" holds true.
Deviations ar *potentially* a FAQ. They become FAQs (AFAICT) based on
frequency of occurrence. On *-dev and *-support, there have been *many*
deviations reported and supported (amicably AFAICT) by the community-at-
large when folks of some experience try different things. Many of these
do not become (and should *not* become) FAQs.

> assumption (fbbg) is actually a dogma which should, IMHO, be adjusted to
> properly reflect the book's audience and the supporting community.

Disagree. What you are implying (intentionally or otherwise) is "change
the book to match some percieved audience other than what is its
currently intended audience". In the discussions on audience mentioned
above, the intended audience has been identified. Changes to the LFS
book (and FAQ) subsequent to those discussions have *intentionally*
changed certain types of content to help service *that* audience and ...
"encourage folks not in that intended audience" (I guess that is a nice
way to put it) to get some more experience or do more reading or...

And again, we want to avoid the "audience" topic. It will draw more than
groans of "Oh no! Not again". And, personally, I'm in agreement and
support those decisions.

> 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 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.

Exception: one recent individual must have had a support request for 50%
of the crap he tried to do. 80% of those were answered by essentially
quoting what was in the book. I have a lot of sympathy/admiration/?? for
all those folks that answered all the posts.

> PS - sorry for the rant. Answering a lot of FAQ's does that to you. I
> initially wanted to post to lfs-chat, but this is all about the book's
> future so still relevant here.

I don't see it as a rant. I see it as an interested contributor
suggesting things that may benefit the community.

Bill Maltby
lfsbill at
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