[ale] RH 7.0 wth boraken compiler

[Fulton Green]

For some "RTFM"-style insight on GCC, consult http://GCC.GNU.org/ .

My take: several years ago (or maybe just two years ago), the Experimental
GNU Compiler System (EGCS), which I think was a grounds-up compiler redo,
was tapped by the GNU C Compiler (GCC) project to eventually become the
next-gen compiler system for the GNU project. When that happened, most of
the newer innovations got thrown into egcs while gcc changes were primarily
maintenance. A few months ago, I think the EGCS people merged their stuff
back into GCC, which was subsequently renamed the GNU Compiler Collection to
reflect its increasing support for languages that weren't birthed by the
Kernighan & Ritchie duo. The tip of the GCC tree is 2.97.XX (supposedly not
suitable for general developer usage) and is aiming for a production-quality
3.00 in the (hopefully) near future.

Red Hat has, in general, seemed to have closely tracked the cutting edge of
gcc/egcs/gcc. When egcs was tapped as the new gcc, the next RH release
replaced gcc with egcs. When egcs merged back into gcc, they replaced egcs
with gcc. The big stink with the gcc (version 2.96) that was included with
RH 7.0 appeared to be three issues:
- packaging a self-labeled "pre-production" compiler into a major commercial
  OS release (this prompted the GCC people to bump up the minor version #)
- the additional patching of the GCC package by RH (according to RH, most of
  the patches wound up back in the project's source tree)
- possible application binary interface (ABI) compatibility problems, esp.
  with apps developed in C++ (affecting your ability to run a RH-compiled
  app in another Linux distro)

My personal experience using the gcc compiler that ships w/RH7 has been
pretty satisfactory (though I'm not producing mass-audience binaries with
it). I have compiled several iterations of the 2.4.0-testX releases, and
have had problems w/only one of them (which, in retrospect, was probably a
stupid mistake on my part). I haven't been able to compile the last few
weeks though due to lack of storage (which will hopefully be resolved
Thursday when my new HDD comes in).

The RTFM on glibc is at http://www.gnu.org/software/libc/libc.html . I admit
to not having as much insight in this area, but I belive that the GNU C
Library project, while separate from the GCC project, is inextrictably tied
to it. The short answer is that if you're going to upgrade the compiler on
your older boxen, you should probably add the newer glibc as well. Of
course, this would probably require updating several other components in the
toolchain (binutils, for example).

The big difference btw libc (last updated at version 5.0) and glibc
(currently at version 2.2) is that glibc is thread-safe and more POSIX-
complete. The newer software is probably taking advantage of those features,
as well as newer flags in GCC. Perhaps it's time to bite the bullet and
upgrade those older systems? :)

On Tue, Jan 02, 2001 at 03:25:43PM -0500, Chris Fowler wrote:
> I'm reading the tread on RH use of a broken compiler and am a little
> confused.  I've always used gcc but never egcs?  why are there so many
> different compilers?  If I upgrade gcc on my box do I need to compile egcs
> as well?  Many of my old distributions incluude libc and not the gnulibc
> stuff.  It is becoming difficult to compile newer software on distributions
> such as RH 4.2 and Slack 3.0.  Why is that?
--
To unsubscribe: mail majordomo at ale.org with "unsubscribe ale" in message body.