Perception of LFS

Matthew Reppert 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
> 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"
> 
> 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
modules stuff.)

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

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

> 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
too-
old objcopy when someone twiddled the build scripts a little. Pretty much
the
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
though.

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

Matt

-- 
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 mailing list