[NTLUG:Discuss] Evil GCC-2.96

[Jim Wildman]

I would like to add a couple of things.

I've been using RH7.x since before it came out (I have a friend on
the private beta testers list :-) )  The only thing I've had trouble
compiling (and I build alot) is VMWare before it was 'officially'
supported on the 2.4 kernels..not just RedHat.  I've yet to find any
program that would compile on another distribution and not on RedHat 7
due to gcc issues.  (I've run into bad code, bad autoconf, bad headers,
but not compiler related issues)

Below is the first part of an interview with Mike Tiemann, the CTO of
RedHat which was done on 11/27/2000.  The complete article is at
http://www.freeos.com/articles/2801/2/11/

A couple things to point out.  The compilers are object code incompatible,
not source code, unless you are using calls into glibc which have changed.
This means you can't compile something to .o files on one version and
expect them to build the rest of the way on the other.  As Mike notes,
this would have been true between RH6,7 and 8 even if they had used the
stock 2.95 gcc.

Also note that they had reasons (which you may or may not agree with),
were not off doing it in the dark (85 patches is a significant pile), and
have been contributing everything back to the cvs tree.  Another unstated
reason is that the FSF has tended to drag their feet on completing new
versions.  RH did the same thing with RH6.0 by using a new version of
glibc.  The new glibc was better, faster, stronger, but 'only' 98% done.
We are all better off for the pain now.  RH tends to be aggressive in
switching to newer/better versions of utilities.

There was also a similar post to Slashdot by the lead gcc maintainer at
RH going into more detail.  Haven't been able to find that one.  The
quote in the article from Richard Henderson is probably what I'm think-
ing of.

<--snip-->
Why did Red Hat decide to ship a development snapshot of GCC instead of the
most recent released version, 2.95.2?

There was a lot of discussion about this on Slashdot when Red Hat 7 shipped,
and with 20/20 hindsight, it appears that no better technical decision could
have been made. I will leave it to speculation as to whether we could have
navigated certain political minefields better, but let me explain the
rationale again.

Red Hat has many different constituencies, ranging from enterprise customers
to ISVs to kernel developers to systems vendors. It would have been great if
GCC 3.0 had been a released compiler and had all the quality, performance,
functionality, and features that our various constituents required. Alas, GCC
3.0 is very much a work in progress, and while we've contributed significantly
to that work (many Red Hat engineers are full-time GCC developers), GCC 3.0 is
still quite a ways off. At the same time, the latest released version of the
compiler, 2.95.2, had a number of significant issues that made it an
inappropriate choice. There were issues related to newer kernel development,
issues related to newer glibc development, issues related to the ever-changing
C++ standard, and issues related to processor support (we wanted to make Red
Hat 7 a first-class IA-64 development platform). After careful analysis, we
concluded that if we tried to bring 2.95.2 up to the level that we required,
it would duplicate large amounts of work that we and others had already done
on the development snapshot. We decided it would be better to stabilize that
snapshot, than add more features to a compiler that had already given us a
certain amount of trouble. I think that Richard Henderson, one of the main
GCC developers summed it up best on the kernel developer's mailing list:

If you want to blame someone in Red Hat for making the decision to ship a gcc
snapshot, then you might as well blame me.

The reasons are the following:

1. 2.95 is the least stable release that we (the fsf gcc team) have shipped
in a long time. It does ok on x86, but is pathetic on the other platforms
that Red Hat cares about -- especially Alpha.

The late July snapshot we shipped is most definitely more stable, largely I
think due to Geoff's automated regression tester bitching at people when they
break the tree.

2. C++ in 2.95 is already ABI incompatible with egcs 1.1 and gcc 3.0, so
clearly (to my mind anyway) it didn't matter whether we shipped 2.95 or a
snapshot, we would still be incompatible with Red Hat 6 and Red Hat 8.

3. While the C++ ABI for 3.0 is not complete, the API is. That is, the
snapshot we chose will be compatible with 3.0 at the source level. With the
exception of "export" I understand from Jason that we are now very close to
standards conformance.

4. We could either spend our QA time reviving the dead 2.95 branch, or we
could spend that QA effort on mainline, helping get 3.0 stable.

Someone on this thread complained that the RPM that we shipped is highly
patched. Bar two (the sbreg_byte patches), all of those patches are in
current cvs. Since at some point procedure would not allow us to take a new
snapshot, those 85 patches are a visible side effect of the QA work that was
done.

Frankly, I didn't even consider C++ ABI compatibility with other Linux
vendors, since I think that's a losing proposition until everyone is using
gcc3. We were _already_ incompatible, since there are a mix of egcs and gcc
versions involved.

Red Hat has worked incredibly hard to make Red Hat 7 the best Linux
distribution ever, and I think we did a great job balancing a lot of complex
requirements. Did we make some mistakes? Yes. Are we fixing them? Yes. In
fact, with Red Hat Network, it's easier than ever to be a part of the progress
we're making, and I invite people to check it out at
http://www.redhat.com/network


------------------------------------------------------------------------
Jim Wildman                                 Lead Consultant, divine, Inc
jim at rossberry.com                                 jim.wildman at divine.com
www.rossberry.com                                         www.divine.com
                                                            (972)560-7356
All opinions expressed are mine and not my employer's.