Re: Compiler for Red Hat Linux 8

[Joe Buck <jbuck@synopsys.COM>]

Geoff Keating writes:

> It's now time for us here at Red Hat to begin planning for the next
> major Red Hat Linux release.  One of the first questions that we're
> looking at is "which compiler should we use?"

While I am an SC member, I am speaking only for myself in this message.

Red Hat's decision has an effect on many people, in many capacities: the
non-Red Hat gcc developers; application developers (free software or
otherwise) who target GNU/Linux; users of Red Hat; users of other
GNU/Linux distributions.

> At present, we have three compilers for the linux releases.
[ egcs-1.1.2, 2.96-RH, GNUPro ]

Rather, three for *your* releases.  A number of other GNU/Linux
distributors (e.g. Debian) use 2.95.x, plus minor patches.
So there are really four distinct gcc versions in widespread use
on GNU/Linux, all binary-incompatible.

(one way to really piss people off, without intending to do so, is
to make statements that give the impression that you think that
Red Hat == Linux.  I know that you didn't mean to, but you wrote
"the linux releases".  Please be more careful).

> We'd really like to get this list down to one compiler.

Looking at the larger world, we're probably talking about three compiler
groupings: 2.95.x, 3.0.x, and GNUpro, as people move away from egcs-1.1.2.
If 3.0.x and GNUpro are pretty closely source and binary compatible,
though, we will have two groups of compilers for binary-compatibility
purposes.  I would recommend developing some kind of test framework
for binary compatibility to catch breakage before things ship.

> So, one plan being considered is that we take a compiler out of the
> Red Hat internal tree (based sometime after 3.0), make a release, and
> ship that as the default compiler.  Then if we can make the kernel
> work with this compiler, we have one compiler, which we can fully
> support.  We didn't have time to do either of these for RHL 7, but we
> do for RHL 8.

If you can fix the Linux kernel and/or GCC so that any compatibility problems
are gone, and contribute these changes upstream (successfully negotiating
the politics involved), that would be terrific.  (That is, we should wind
up with both GNUPro and FSF-3.0.x building the new kernels correctly).

> The other problem with what we did for RHL 7 was that it was difficult
> for other distributors to be compatible with our system, because the
> 2.96 snapshot wasn't binary-compatible with any FSF release.  With the
> release of GCC 3.0, this shouldn't happen for the new compiler; other
> distributors will be able to use any 3.0-compatible compiler.

That's a necessary but not a sufficient condition.  We still haven't
frozen libstdc++'s ABI; we can't because it isn't really done and still
could be made better by more refactoring of templates and such.  To have
GNU/Linux applications portable between distros that use your compiler
and those that use FSF releases, you'll need to use the FSF version of
libstdc++, or make sure that any deviations don't break binary
compatibility.  It will be tempting to make some improvements.  Resist
that temptation.

> [I know IA64 has a completely different set of problems; I'm mostly
> concerned about IA32 and Alpha at this point, but if anyone has
> suggestions about IA64 we're happy to hear them; the main problem
> seems to be that the ABI for IA64 is still changing, but the internal
> tree is better for IA64 than the FSF releases at this point.  I also
> know about the glibc issues on all platforms, but that's a separate
> issue also.]

I don't know enough about IA64 issues to comment.

glibc is a sensitive matter; a number of us got rather nervous to see a
couple of glibc developers advocating the use of gcc-2.96-rh instead of
getting the 3.0 problems fixed.  To the extent that a number of glibc
developers work at Red Hat, I ask that you be sensitive to this.  Folks
who've taken on the task of maintaining packages for the FSF need to make
sure that they work together.

> So, how do people feel about this?  Does the SC have an opinion?

I do have concerns (that the world's largest concentration of gcc
developers will be putting their energy into a fork of gcc, rather than
the net gcc), but evidently you have decided for business reasons that
this is the way to go.  This is your right, but I hope that you make
efforts to keep the divergence small by regular re-syncs with the FSF
gcc tree.  The old Cygnus model was, in effect, that you were selling
what the FSF gcc would be like six months ahead, today.  I suppose I
could live with that, though it would be preferable not to have to.

Speaking personally, as a C++ developer my ideal world would be to write
to one fairly standards-conformant front end, say gcc-3.1.x, for all
platforms that I need to support.  However, I doubt that Red Hat has much
interest in supporting Solaris, HP/UX, or AIX (at least without special
contracts), so if your front end has a different set of bugs, it might be
easier just not to use it, even if that means (for the kind of compiled
simulation work that I do) shipping a complete copy of the FSF gcc to run
on Red Hat 8.x.  Each additional C++ compiler tends to mean a different
set of bugs and support issues.