"Brian T. Brunner" <brian.t.brunner@xxxxxxxxxxxxxxx> wrote:
> Not necessarily... gcc 2.9x LOVES my code, and the program
> built under it runs like a champ.
GCC 2.9x was also a very long set of betas that:
1. 2.91 -- Replaced legacy GCC 2.8 with the Enhanced GNU
Cygnus Compiler (EGCS). 2.91.66 ~ EGCS 1.1.2
2. 2.95 -- Improved ANSI C compliance, multi-architecture
support, other capabilities, while maintaining most ANSI C++
compatibility with GCC 2.8
3. 2.96/2.97 -- Forced ANSI C++ compliance and made heavy
structure changes to support various targets, breaking a lot
of C++ compatibility and legacy GCC 2.8'isms
NOTE: Due to Red Hat's need for the work-in-progress (WIP)
IA-64 target of 2.96, subsequent changes were checked-in as a
new 2.97 which became 3.0.
> gcc 3.4 barfs on this same source code, so I see this as
> "Stoopidly Pedantic" on the part of the compiler-writers.
Blame the GNU 2 maintainers then. They didn't maintain
alignment with a lot of standards. Heck, they were rather
_poor_ and maintaining compatibility between GCC 2.x
releases. Red Hat skipped 2.8 altogether and went from 2.7
to EGCS 1.1.2 _before_ the FSF even gave Cygnus control of
GCC 3's development (and this was well before Red Hat bought
Cygnus).
There is a reason why the FSF turned GCC 3 development over
to Cygnus. I'm surprised they were able to do what they did.
In reality, GCC 2.95 and, subsequently, 2.96 should have
_never_ existed. Distros should have stuck with 2.91.66 and
waited on 3.0.
Many distros adopted GCC 2.95 when GCC 2.91.66 (EGCS 1.1.2)
was still being used for the kernel. It's C was rather buggy
until 2.95.3 (probably the best release), and even 2.95.4 had
some quirks.
Red Hat stuck with EGCS 1.1.2, but then found newer software
would not build on GCC 2.91.66 when it decided to form its
next distro. They also had a real need for the IA-64 target,
so they put forth the 3 months of effort to bring the C of
the current GCC 2.96 tag up to quality. They also worked on
various C++ code that was not ANSI C++ compliant.
Unfortunately, the C++ code of 2.96 was still heavily ANSI
C++ oriented and did not support much GCC 2.8 C++
pre-processor directives at all. So a lot of C++ code broke
and would not build on 2.96. That was the duty of the
retagged 2.97, which would become 3.0. Despite all the
complaining, C++ code _still_ had to be modified to build on
3.0, even if it did on 2.91.66.
In fact, one would argue that wide-spread adoption of 2.95
made the situation worse.
> Things that work and stop working because of a "better
> compiler" bring into question the definition of "better".
Again, blame the GCC 2 maintainers.
Since GCC 3.0 came out, application binary interface (ABI)
compatibility has been rather _outstanding_! Epecially as of
GCC 3.1, through the very latest 3.4.
Even GCC 4.0 is far less of a change from 3.1 than GCC
2.91.66 (EGCS) was to 2.95/2.96 or the final 2.97/3.0.
Cygnus knew what it was doing. Had people not adopted the
2.9x releases _other_ than 2.91.66 (EGCS 1.1.2), and waited
on the 3.0 release, there would have been far less issues.
Instead, a lot of distros adopted 2.95, which resulted in a
lot of issues -- beyond just what GCC 2 already had. But
since 3.1, there's been far, far less. Just as Cygnus
promised the FSF, and they were right.
-- Bryan
P.S. Don't get me started on the GLibC 1 and the LibC 4 and
5 forks, then the return to GLibC 2. Reality: Since the
adoption of GLibC 2 and GCC 3, the Linux world has been far,
far better off. ;->
--
Bryan J. Smith | Sent from Yahoo Mail
mailto:b.j.smith@xxxxxxxx | (please excuse any
http://thebs413.blogspot.com/ | missing headers)
