Perception of LFS

Matthew Reppert repp0017 at
Tue Jan 14 14:40:21 PST 2003

On 14 Jan 2003, Gerard Beekmans <Gerard Beekmans
<gerard at>> wrote:
> On January 12, 2003 03:48 am, Greg Schafer wrote:
> Back to what we can do to enhance the perception. Other than writing the
> in technical sound way and not spreading around bullocks in the book I
> think of anything else we can do. Market the book in hopes that famous
> people hear of it and actually try it out?

You know, there is one thing I'd like to suggest, although it may open up a

new field of issues. Currently, I doubt there are many distributions that
a package straight from the distribution tarball, compile it for an arch,
it to make sure it doesn't blow up, and stick it straight into their
database. Instead, many packages end up having that familiar "-number"
to the end of their version.

This is because, of course, the distributions go and patch up bugs in stuff
they release. We do, but I know in the past we've missed a couple of
things, namely in our toolchain. My reference for most of this is Debian,
it's what I've used in the past  ... their current 2.95 gcc is 2.95.4 
(prerelease), which is based off of the Oct. 6 gcc CVS. Against that, they
18 patches for Linux-i386 to build C, C++, and Objective C. Now, a few are
trivial, like "change the version to 2.95.4 Debian prerelease" and "fix up
filenames to install like Debian wants", but there are still 8 patches that
fairly important. One of them fixes the gas .hidden detection issue we were

having with 2.95.3. Another one fixes a bug in the strength reduction 
optimization, which *is* included in the -O2 optimizations and fails
with a simple test case on powerpc.

Now, my last LFS system (before the one I'm running right now) was built
two months before Alan's comments. When I read it, I thought about things
a while and decided I'd basically use Debian's source packages for gcc and
benefit from their QA. (Note, this is just my solution. It was a pain
out how to patch up my compiler "just like Debian's" the first time without
the benefit of Debian development tools.) The system I just built last week
gcc 2.95.4 as a result. I also grabbed some 3.2.1 patches from them (there
only 6 that their makefiles said applied to my platform, but there are 42 
patches in the patch directory). My point is, I can see how our toolchain
get subtle little bugs. Subtle little bugs can play hell with the kernel.

Now that I've rambled for a page or more about this, what can we do about
Well, I guess that's open to debate about a few things. I noticed that a
people here are keeping tabs on some of the project mailing lists, and I
that's a good thing. Personally, I think it'd be great to have people keep
on things like that and forward patches to the book. (For critical
problems, is
it possible to change the current release of the book to add patches?)
the most important things in this respect are probably gcc, binutils, and
since they're probably the things that 1) will screw you over the most if
break, and 2) are complicated enough to make breakage that more easy (this
a subjective observation). Oh, and the kernel, to some extent; now that I
about it there was a nasty ext3 journal=data bug that only recently got
The problem with this is that it can take time to keep up with this stuff, 
especially when we're dealing with high-volume mailing lists. So I'm not
how much we can realistically expect. Of course, if our policy is just
until releases fix things" it doesn't matter as much, but (for example) we
gcc 2.95 in for so long that I think it would have been nice to have a note
said something like "This bug has been noted, here's a patch that's not in
official FSF release yet". (I only found out about this in particular
though ... )

Comments? Good idea? Waste of time? Good idea but perhaps too much on our
current resources? Or am I just blowing out so much hot air? 
(I've interpreted some of what Alan has said about "running the latest and
greatest off" as having to do with this sort of issue .. )

(By the way, on a totally unrelated note, if I come up with something I
should go in the book, this is the place to go, right?)


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