From: Geoff Keating <geoffk@geoffk.org>
To: gcc@gcc.gnu.org
Subject: Re: Compiler for Red Hat Linux 8
Date: Wed, 18 Jul 2001 14:33:00 -0000 [thread overview]
Message-ID: <200107182149.OAA10449@geoffk.org> (raw)
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>
next reply other threads:[~2001-07-18 14:33 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-18 14:33 Geoff Keating [this message]
2001-07-18 14:43 ` Netwinder GCC build fails on "make bootstrap" Robert E. Hartley
-- strict thread matches above, loose matches on Subject: below --
2001-07-19 23:16 Compiler for Red Hat Linux 8 Bernard Dautrevaux
2001-07-19 10:49 dewar
2001-07-19 4:33 dewar
2001-07-19 1:36 Bernard Dautrevaux
2001-07-19 2:40 ` Joseph S. Myers
2001-07-19 3:02 ` Roman Zippel
2001-07-19 3:12 ` Russ Allbery
2001-07-19 0:29 Bernard Dautrevaux
2001-07-19 1:16 ` Toon Moene
2001-07-18 20:02 dewar
2001-07-18 14:41 dewar
2001-07-18 15:29 ` Geoff Keating
2001-07-18 17:50 ` Joe Buck
2001-07-18 18:59 ` Michael Eager
2001-07-18 19:26 ` Justin Guyett
2001-07-19 9:05 ` Mark Mitchell
2001-07-19 19:28 ` akbar A.
2001-07-18 22:10 ` Per Bothner
2001-07-18 22:19 ` Joe Buck
2001-07-18 22:38 ` Per Bothner
2001-07-18 23:00 ` Alex Rosenberg
2001-07-19 14:05 ` Jonathan Larmour
2001-07-18 13:21 Benjamin Kosnik
2001-07-17 20:00 Benjamin Kosnik
2001-07-17 17:37 mike stump
2001-07-17 13:04 Geoff Keating
2001-07-17 15:52 ` Joe Buck
2001-07-17 17:48 ` Per Bothner
2001-07-18 8:55 ` Joseph S. Myers
2001-07-17 18:24 ` Craig Rodrigues
2001-07-18 2:41 ` Andreas Jaeger
2001-07-18 9:03 ` H . J . Lu
2001-07-18 12:01 ` Joe Buck
2001-07-18 12:46 ` H . J . Lu
2001-07-18 13:22 ` Joe Buck
2001-07-18 13:31 ` H . J . Lu
2001-07-18 14:28 ` David Edelsohn
2001-07-18 15:03 ` Joern Rennecke
2001-07-18 15:12 ` David Edelsohn
2001-07-18 15:24 ` Joe Buck
2001-07-18 17:05 ` H . J . Lu
2001-07-19 4:56 ` Toon Moene
2001-07-18 15:41 ` Joseph S. Myers
2001-07-18 16:23 ` H . J . Lu
2001-07-18 12:18 ` Sergey Ostrovsky
2001-07-18 15:19 ` Ken Whaley
2001-07-18 15:30 ` Toon Moene
2001-07-18 15:59 ` Ken Whaley
2001-07-18 16:08 ` Toon Moene
2001-07-18 13:30 ` Gerald Pfeifer
2001-07-19 5:17 ` Andreas Jaeger
2001-07-19 12:23 ` Gerald Pfeifer
2001-07-18 19:07 ` LinuxVN
2001-07-18 13:44 ` Toon Moene
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200107182149.OAA10449@geoffk.org \
--to=geoffk@geoffk.org \
--cc=gcc@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).