Not necessarily... gcc 2.9x LOVES my code, and the program built under it runs like a champ.
gcc 3.4 barfs on this same source code, so I see this as "Stoopidly Pedantic" on the part of the compiler-writers.
Things that work and stop working because of a "better compiler" bring into question the definition of "better".
Brian Brunner brian.t.brunner@gai-tronics.com (610)796-5838
chrism@imntv.com 10/24/05 10:39AM >>>
Tom Brown wrote:
Hi
CentOS4.2 - Is it possible to have an older version of gcc as well as the one that ships with this OS? I need to compile aspseek to run on this distro but it seems to only like older gcc's
any ideas?
4.2 ships with a recent vintage GCC 3 and there's an option to include GCC4. If your program won't compile with a very stable GCC3, then you might want to fix the broken software rather than install an obsolete development environment, no?
Cheers,
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
******************************************************************* This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager.
This footnote also confirms that this email message has been swept for the presence of computer viruses.
www.hubbell.com - Hubbell Incorporated
Quoting "Brian T. Brunner" brian.t.brunner@gai-tronics.com:
Not necessarily... gcc 2.9x LOVES my code, and the program built under it runs like a champ.
<flame mode="on"> "Try this and see if compiler or interpretter complains" approach is discutably OK for one-time use Perl scripts. It's a very bad approach for C code that should be used (and, oh my God recompiled) 5 years after it was written. </flame>
If your code conforms to ANSI, file a bug with gcc folks. If it doesn't conform with ANSI, it's you who are at fault. Don't blame the compiler for your mistakes of the past.
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
Aleksandar Milivojevic alex@milivojevic.org wrote:
If your code conforms to ANSI, file a bug with gcc folks. If it doesn't conform with ANSI, it's you who are at fault.
Don't blame the compiler for your mistakes of the past.
This "fault" thing has gotta go.
Because, ultimately, it was GCC 2 that was "at fault" when it came to ANSI C++ (let alone some ANSI C). But GCC 2 had a lot of legacy behind it, much of which _pre-dated_ ANSI C++ standardization. So where does the finger-pointing end?
In the end, as of GCC 3, the world is a lot better.
"Brian T. Brunner" brian.t.brunner@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. ;->
-
Aleksandar Milivojevic -
Brian T. Brunner -
Bryan J. Smith