Perception of LFS
repp0017 at umn.edu
Sun Jan 12 10:03:56 PST 2003
On 12 Jan 2003, Billy O'Connor <Billy O'Connor
<billyoc at linuxfromscratch.org>> wrote:
> gschafer at zip.com.au (Greg Schafer) writes:
> > Alan Cox says:
> > "I get so many weird never duplicated reports from linux from scratch
> > 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
> > kernel with Debian/Red Hat/.. binutils/gcc"
> If Alan Cox doesn't want kernel bug reports from LFS users, I'd be
> more than happy to oblige him, and not send any. I get the same sort
> of "raised eyebrow" response from Gnome developers, who don't know
> anything about LFS. My personal policy in this regard is to reproduce
> any bug I find on Debian, etc., before sending it in.
This annoyed me greatly when I first read it back in November(?), it was
pretty much all I could do to keep from emailing a "look here, that's just
wrong" message in cold blood :) I think the best thing to do is probably
encourage testing by People-Who-Know-What-They're-Doing in our community
and have them send reports as they find them. Kind of a signal that yes,
not everyone who does this screws up majorly.
(As an aside, I'm by no means suggesting putting this in CVS, but 2.5 is
really starting to shape up on some configurations; I've been running it on
my LFS desktop since 2.5.41 or so without problems. If you want to test the
water, and you're all backed up, it might not be too painful except for the
> > Now THAT is the kind of thing that makes my blood curdle. See my
> > post about binutils. Maybe we should upgrade to HJ's binutils so that
> > "keeping up with the Jones's" and we are not treated like black sheep.
> > maybe we should start building the kernel with gcc-2.95.x like the docs
> > say.. And maybe we should start... etc, etc, etc...
> As far as using the HJ binutils, wouldn't we be excluding non x86
> users, or am I misunderstanding that? I thought the HJ "fork" was x86
Nope. If you look at release notes, it's got fixes for several archs, in
fact. It's Linux only, but it should go to all the archs FSF binutils does.
(Occasionally more, if it happens to make a release with a fix before FSF
> Surely Cox wouldn't suggest using them though, right?
I bet he would. Actually, it was that thread that flagged the "look into
H J Lu binutils" bit in the back of my mind a couple months ago.
> Maybe we should test all kernel related problems against kernels built
> with whatever toolchain lkml approves of, at least.
There really is no "toolchain lkml approves of", it's pretty much whatever
goes into standard distributions. (With occasional exceptions, gcc-2.96
anyone?) There really is a wide variety of things used; for example, akpm
still uses ecgs 2.91, and is basically the driving force behind keeping the
kernel compilable with it. Recently a bunch of people got caught with a
old objcopy when someone twiddled the build scripts a little. Pretty much
only guidelines are what's in Documentation/Changes and maybe some unspoken
agreements on what's sane. 2.95.x is still the agreed-on "best" compiler
As long as we're on the note of kernels and gcc ... a couple people I know
have been compiling 2.5 with gcc 3.2 for a while without notable problems,
and there've been changes in 2.5 over the past couple releases basically
marked "make xxx compile with 3.2" (since it's stricter about some things).
It's *probably* okay to do kernels with 3.2.1 (as opposed to 3.0), it just
naturally isn't as well tested. Also, I don't know if anyone is current
NPTL, but that requires glibc 2.3.1, which requires gcc 3.2 or better, so
there *are* people out there using 3.2 that are generally accepted as clued
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