Perception of LFS

Dagmar d'Surreal no.spam at
Sun Jan 12 19:12:37 PST 2003

On Sun, 2003-01-12 at 06:10, Jesse Tie-Ten-Quee wrote:
> Yo,
> On Sun, Jan 12, 2003 at 09:48:16PM +1100, Greg Schafer wrote:
> > "I get so many weird never duplicated reports from linux from scratch people
> > that don't happen to anyone else that I treat them with deep suspicion.
> > Especially because it sometimes goes away if they instead build the same
> > kernel with Debian/Red Hat/.. binutils/gcc"
> I think he does have a point, as MSB mentioned.  However... they were not
> exactly being fair, either.  Reading through the thread, he blames our
> toolchain, but in no way points to anything in particular... but does
> imply we are not building it properly.  Confusing at best.

This *definitely* irks me, especially considering that LFS builds the
toolchain in almost the exact same way I've been doing it for years,
with a few (IMPO) completely non-material differences.  There's some
stuff going on (esp. now with glibc) that could be considered slightly
questionable, except for the fact that all the questionable bits have
been researched to hell and back and are working just fine.  I *suspect*
he's basing this analysis on his experience with random LFS users rather
than LFS itself.  

> They also mentioned-and discredited us on our lack of GNU or high profile
> developers.  All I can say is.. hey, if you happen to know anyone that's
> free, send them our way.  We have managed without them, and i've never had
> a kernel issue with LFS, so.. whatever.  I don't see that as a fault on
> our part, we *are* a small project after all.  But we would all welcome
> additional help :)

That was just a silly argument for him to make, IMHO.

> Dunno.  Sounds like he's just had his fair share of reports from lfs users
> that are doing what we have always encouraged-tweaking and modding there
> systems to there own requirements-eg no where standard compliant; that
> always causes problems, heh.
> > Now THAT is the kind of thing that makes my blood curdle. See my earlier
> > post about binutils. Maybe we should upgrade to HJ's binutils so that we are
> > "keeping up with the Jones's" and we are not treated like black sheep. And
> > maybe we should start building the kernel with gcc-2.95.x like the docs
> > say.. And maybe we should start... etc, etc, etc...
> I can see many reasons for using HJ's binutils.
> However, using _this_ is not a reason that should be considered if that
> switch is to take place.  There were no technical issues discussed, just
> people complaining because we were not using the same version of software
> with their patches applied and were causing problems.  *shrugs*

I've gotten this argument from the Gnome guys so many times that I've
taken to regularly raiding SRPM stashes to see what magic thing it is
that they're doing to problem packages that no one's bothered to put
into the release tarball or Bugzilla yet.  I consider people developing
binaries independently of the code authors a very valuable form of QA, 
because it uncovers problems relating to flawed assumptions about the
build environment by the bushel.

> If you can't use the official standard GNU software to build a linux
> system.. like wtf.. why are we the ones being blamed? :P

Because for every legitimate bug that LFS is the cause of discovery,
they are probably about a dozen or more not-bugs that turn out to be
caused by someone's crazed attempt at optimizing their compiler, or
haphazard build of glibc, or that they skipped chapter 5 entirely and
don't realize their toolchain is effectively cooked

I mean, c'mon... the 4.0 book lists a particular version of Bison
(1.35), which is apparently what everyone writing software that invokes
bison is using, yet many LFS users who aren't using the CVS version of
the book still insist on trying to use the highest numbered version
instead (which for other packages wouldn't be such a bad idea), and then
report problem after problem because of incompatibilities between the
versions.  Yes it would be nice if bison could be totally fixed, but
since that's a very glacial problem, we're back to the basic problem of
what to do when the instructions are ignored.

(and on this issue I think CVS should mention that for many problems
relating to Bison, the quickest fix is to temporarily install 1.35
instead of 1.75.)

> And personally the comments about LFS being on the bleeding edge is not
> really true.  Our users may live on the bleeding edge, but the actually
> book and all the software we promote is stable and well tested-to the best
> of our abilities, given our resources and people.

Calling LFS bleeding edge is something that I suppose would require
someone call Debian Sid "current".  Bleeding edge would be the CVS
version of the book, which would be appropriate.  "Cutting" edge is as
close to the edge as LFS can reasonably be accused, IMHO.  I don't want
to have to be the one to point out that AC is human and can make
mistakes, but it certainly seems to me that _if someone follows the 4.0
instructions to the letter_ the result is something far less bleeding
than RedHat's little mouseterpiece.

> Many of us still remenber when RH 7.0 was released with GCC "2.96" as the
> default compiler.  I happen to remenber how much faith Alan had in RH and
> helping promote the good side of things about it.  Looking back over the
> years; Redhat, Mandrake, SuSE, Gentoo, etc... are by far the ones that
> "live" on the bleeding-edge _officially_.

Too true.  ...but at least Gentoo admits to it.

> I wont get started on the gcc3 thing Greg, as you honestly do not want to
> go there-trust me ;)
> > Does anyone care about these sorts of issues?
> I care that the technical issues get resolved.  I could care less if the
> developers are slapping us from afar, without giving us a hand.  The only
> thing gained by reading a thread like that, is loss of respect for a
> developer i've always held high.  Unless he wants to elaborate a little
> futher on some of the causes of our toolchain problems (thou he expressed
> not w/o some $$$ :) or get us talking to some developers that could help
> fix our problems, or at the very least point us in the right direction...
> Whatever.
> Either way, I still highly respect Alan Cox and i'm sure he has his
> reasons for his comments.  But without facts to back it up, all we have
> now is a mystery.  Not really an issue i'm going to loose sleep over ;)

Hopefully at some point in the near future someone will be able to coax
some more details out of him about what, specifically, he thinks is

(rest snipped)

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