GCC 2.95.3 [LFS/BLFS conflicts]

Matt Reppert arashi at yomerashi.yi.org
Mon May 12 12:07:30 PDT 2003

On Mon, 12 May 2003 19:03:13 +0100
Ian Molton <spyro at f2s.com> wrote:

> On Mon, 12 May 2003 17:57:33 +0000 (UTC)
> gerard at linuxfromscratch.org (Gerard Beekmans) wrote:
> > I don't agree that having two compilers is a pain in the arse. It'll
> > be put in /opt so it's out of the way and you don't put it in $PATH
> > unless you really need it. It'll never get in the way. I believe the
> > pro's far outweigh the con's.
> You should remember that whilst the 'kernel developers' may recommend
> it, some of their recommendations have been completely nutso. 

Like what?

> things
> like using a really retarded compiler like 2.95.1 or something stupid
> because <insignificantarchitecturenumbertwentynine> miscompiles
> <neverheardofitbefore> support under <notbloodylikely> conditions.

You're missing the point. See below. It would be nice if you backed up
a statement like that with other specific examples, lest you fall into
the same thing people bitched about Alan for commenting on "linux from
scratch" people on this same list.

> Who here has *ACTUALLY* had a problem using gcc 3 to compile kernels
> (and I mean a recent version, not gcc<nearlybutnotquite3fromcvs>)?

Me. Using 3.2.2 or 3.2.3. No, it was not on i386.

> Exactly what failed? and did you submit a patch to fix it to the kernel
> or gcc team?

The kernel wouldn't boot compiling with 3.2.x. It would mysteriously stop
during SCSI initialization, waiting didn't help. I haven't had time to try
to diagnose anything less obvious than compile errors lately, unfortunately.

> The current situation:
> gcc-2.95.3 - miscompiles some kernel features
> gcc-3.x.x - miscompile some kernel features.
> The only difference is in which features get miscompiled.

No, the point is that 2.95 has had lots of testing. 3.{2,3,4} have had
relatively little testing. 2.95.x (x >= 3) have been relatively proven,
the newer versions haven't. It's just a question of "don't jump to new
releases immediately because it's not safe". That's even what's said in
Documentation/Changes. Any bugs left in 2.95.3 are pretty much known and
worked around if they effect the kernel, but I've seen more workarounds
for 3.x compilers than 2.95.3 (this probably just dates me more than
anything else though ^^; ).

Honestly, I don't see why you're so adamantly against preferred use of
2.95.3 *only for the kernel*. It's the *safer* thing to do, so it goes
in the main book for people who haven't read up on the situation and such.
That's generally the way the main book releases tend to lean. People who
know what they're doing don't have to follow the book, so I'm not sure
why this is such a big deal.

It's not like the kernel developers have some sort of fetish for ancient
toolchains (except maybe akpm -_^ ); they recently (well, in October or
November) had to up the minimum required version of binutils due to some
change or another.

BTW, No distribution uses the actual gcc 2.95.3 release anymore, it's CVS
plus any patches that haven't been/won't be integrated upstream. I also
don't use straight gcc 2.95.3 on any systems I build it on, but use Debian's
version. Since the vast majority of Linux systems are from some distribution,
which have a gcc 2.95.3 package that's slightly newer than the actual 2.95.3
release, I think that makes this recommendation all the more reasonable. 

Of course, I also compile my desktop machine's kernels with the 3.2-branch
compiler I have handy, but I've noticed software always seems to break on
i386 after every other platform, so it's not *as* worrying; then again, I've
also run over 20 releases of the 2.5 kernel. I don't see anyone clamouring to
stick kernel 2.5.69 into CVS, even though it's stable on i386 and "works most
of the time for most common configurations". I know *I've* certainly never had
any problems with 2.5 on my desktop ...

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