"Brian T. Brunner" <brian.t.brunner at gai-tronics.com> 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 at ieee.org | (please excuse any http://thebs413.blogspot.com/ | missing headers)