This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Compiler for Red Hat Linux 8
- To: gcc at gcc dot gnu dot org
- Subject: Re: Compiler for Red Hat Linux 8
- From: Geoff Keating <geoffk at geoffk dot org>
- Date: Wed, 18 Jul 2001 14:49:55 -0700
- Reply-to: Geoff Keating <geoffk at redhat dot com>
A general tone of the responses so far has been "why can't you use a
FSF released compiler without modification?"
I don't think this will be possible.
1. We don't have a process for supporting a compiler that doesn't come
out of our internal tree. We would want to be able to do things
like commit patches to the branch as we send them to customers. I
don't think we'd be able to do this on a FSF release branch.
What's more, we might need to ship a new compiler to a customer
with a patch, which would imply making a new release if we are to
use only released versions.
2. We have fixed deadlines and requirements for the compiler that are
unlikely to be matched by a FSF release process. For instance,
suppose that the compiler is broken on mips-linux at the point when
the branch is frozen for testing by release engineering. At that
point, this means that the release will be broken on mips-linux.
We don't mind, because we aren't doing a MIPS release, but the SC
might; but we can't change our schedules because of it, which means
the release has to go out anyway. The issue of the subreg_byte
patch has already been raised. It also means that we might have to
block patches that could make the release less stable on the
platforms we care about, which are only a small subset of the
platforms that GCC 3.0 supports.
3. It's likely that our releng people would need to be in control of
the release process. This is likely to be politically difficult.
It's probably also not something Red Hat wants to do; we spent a
lot of time trying to convince people that the GCC development
process was independent and not "controlled by Red Hat", but for
this we need the control.
We also don't have a releng process for making releases out of a
branch of the FSF tree. We're already doing something new---this
release will be in RPMs, not the usual tclish installer---and it's
hard to do many new things at once.
4. It's possible that, depending on how the IA64 situation goes, we
might have to have code in the compiler which no-one outside Red
Hat (and not on the appropriate NDA) can see until some point
shortly before the release. I'm not sure how that could be made to
work.
5. We would prefer to ship a newer compiler than something off the 3.0
branch. By the time that this release goes out, the 3.0 branch
will be over a year old. You'll note that RHL 7.2 is not out yet,
and on the normal schedule RHL 8 will be about six months later.
In short, GCC developers wouldn't like it, Red Hat wouldn't like it,
the FSF and the SC wouldn't like it, and it's a recipe for disaster.
This is why I didn't even suggest it in my original mail.
A number of the above points apply even if we are taking a FSF release
and patching it. It's also questionable what benefit doing this has
over using our internal tree; you end up with a situation like that of
the kernel, where it is technically based off a release but it has
around 400 patches applied.
--
- Geoffrey Keating <geoffk@geoffk.org>