[Exim] gcc 2.96 rants (was Re: Re: odd error....)

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Derrick 'dman' Hudson
Date:  
À: exim-users
Anciens-sujets: Re: [Exim] Re: odd error....
Sujet: [Exim] gcc 2.96 rants (was Re: Re: odd error....)
--
On Sun, Jun 16, 2002 at 11:53:30PM +1200, Juha Saarinen wrote:
| On Sun, Jun 16, 2002 at 12:20:30AM -0500, Derrick 'dman' Hudson wrote:

|
| > Say, which compiler are you using? If it's gcc 2.96, trash it.
| > It doesn't exist and was one of RH's biggest mistakes. (it's what
| > pushed me to look around and become very happy with debian)

|
| Unless you have a deep and thorough understanding of compilers in
| general and gcc in particular, don't hand out "advice" like that,
| especially to newbies.


Mmmm, actually, take a look at this :

http://gcc.gnu.org/gcc-2.96.html

Do you really want to give newbies a CVS snapshot of a compiler?

| For the record, I have been compiling Exim (plus the Linux kernel,
| XF86 4, and much more) with gcc 2.96 with zero problems. It works
| fine.


Do you know why RH 7.x includes 'kgcc'?

http://www.crhc.uiuc.edu/~bjb/linux/kernel.html

| http://www.redhat.com/advice/speaks_gcc.html for RH's official take on
| 2.96.


I'm not reading any farther than this :

       * gcc 2.96 has more complete support for C++. Older versions of
         gcc could handle only a very limited subset of C++.


         Earlier versions of g++ often had problems with templates and
         other valid C++ constructs.


       * Most of gcc 2.96's perceived "bugs" are actually broken code
         that older gccs accepted because they were not standards
         compliant - or, using an alternative term to express the same
         thing, buggy.


(well, ok, I did skim farther after all)

This is totally contrary to my experiences. g++ 2.95 can fully handle
the complex templates used by the SigC type-safe signal library
whereas Sun's CC barfed trying to buid it. g++ 2.96 also thought that
the words 'and' , 'or' , and 'not' were reserved words and not legal
structure member identifiers (as used by the cctype library). cctype
is NOT buggy in that respect. The C++ optimizer would just give up
and die while trying to compile Mahogany. This is all on top of a
buggy libc that defined LONG_BIG as 64 on my ia32 system (the python
developers were quick enough to catch that and #error with a decent
message). Need I try and recall other problems it caused?

While I agree that gcc/g++ 2.95 isn't perfect and fully standards
compliant, it is *stable* and *supported* by the GCC development team.
A CVS snapshot is neither; not to mention binary incompatible with all
stable and supported gcc releases.

-D

--

(E)ventually (M)allocs (A)ll (C)omputer (S)torage

http://dman.ddts.net/~dman/

--
[ Content of type application/pgp-signature deleted ]
--