This is the mail archive of the
mailing list for the GCC project.
Re: Compiler for Red Hat Linux 8
- To: hjl at lucon dot org (H . J . Lu)
- Subject: Re: Compiler for Red Hat Linux 8
- From: Joe Buck <jbuck at synopsys dot COM>
- Date: Wed, 18 Jul 2001 12:01:29 -0700 (PDT)
- Cc: aj at suse dot de (Andreas Jaeger), geoffk at redhat dot com (Geoff Keating), gcc at gcc dot gnu dot org
On Wed, Jul 18, 2001 at 11:41:18AM +0200, Andreas Jaeger wrote:
> > I personally would appreciate - and support - a commitment from some
> > of the Linux distributors on the next GCC version they're using and on
> > compatibility to a *released* GCC version.
HJ Lu wrote:
> I think that is the problem. When was the last time any Linux
> distributions used an unmodified *released* GCC? Probably never.
Andreas is talking about compatibility to a released version, he is not
insisting on no patches. A few patches to solve localized problems
(example: Debian's patched 2.95.2) is not an issue; no GNU/Linux
distributor ships unmodified Linux kernels either, for similar reasons.
It only becomes an issue when incompatibilities arise or changes don't get
merged back in.
These mini-forks are not a problem because everything keeps getting
re-synced again. It's only an issue if things start growing apart
or people can't resolve their differences.
> of the *released* GCCs was good enough to build a whole Linux
> distribution. Every vendor has to modify a *released* GCC or
> take a snapshot from CVS. One way to solve it for Linux is to have
> a vendor-natural Linux gcc, which is known to be able to compile
> a complete, working Linux distribution. But given the release
> schedule of gcc, unless a Linux distribution wants to sync their
> release schedule with gcc, which I don't believe is likely to happen,
> I don't think such a Linux gcc will be a *released* GCC.
Given the circumstances in the last couple of years, this is
understandable. Something like 2.95.3 should have come out ages
before it did, but we weren't in a position to do releases at that
time because we had no release manager. I'd like to get 3.0.x in
shape to be usable for complete GNU/Linux distributions as soon
> why I suggested making bug fix releases of gcc every 2 or 3 weeks
> so that there is a chance that we can use a *released* GCC for
> Linux distributions. Of course, I am assuming that those bug fix
> releases fix the reported Linux build bugs.
It's not necessary to do a whole lot of releases to make this happen: we
have a 3.0 CVS branch. Volunteers who care about this can build from a
CVS gcc (or download prebuilt releases from daily snapshots, like those
CodeSourcery provides) and report failures. Our target for 3.0.1 is
August 1. But it's not necessary to wait until that date to help find and
And remember that there will be lots of problems in apps as well as the
compiler. Incorrect #ifdefs that break with the bump in major version
number; invalid C++ code that happened to work with 2.95.x, etc.