On Sun, Jun 16, 2002 at 09:04:41AM -0500, Derrick 'dman' Hudson wrote:
>
> 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?
It's not the same as 2.96-RH, and this issue has been hashed over
many, many times already.
>
>
> Do you know why RH 7.x includes 'kgcc'?
>
> http://www.crhc.uiuc.edu/~bjb/linux/kernel.html
Sure:
$ rpm -qi compat-egcs
Name : compat-egcs Relocations: (not
relocateable)
Version : 6.2 Vendor: Red Hat, Inc.
Release : 1.1.2.16 Build Date: Thu 12 Jul
2001 07:34:57 AM NZST
Install date: Sat 24 Nov 2001 01:43:49 AM NZDT Build Host:
porky.devel.redhat.com
Group : Development/Languages Source RPM:
compat-egcs-6.2-1.1.2.16.src.rpm
Size : 3052280 License: GPL
Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL : http://gcc.gnu.org/
Summary : The GNU Compiler Collection for Red Hat 6.2 backwards
compatibility
Description :
This package includes a compiler that can be to generate binaries that
will run on older Red Hat Linux systems (namely Red Hat Linux 6.2).
This package includes the C compiler and required compiler libraries
for those systems.
This is not what I use for compiling Exim or the Linux kernel.
>
> 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?
Can't comment on the libc bug, but I just built the wxWindows libs and
Mahogany here. With gcc 2.96, and yes, the binaries work. I note
that wxWindows which Mahogany depends on has a few problems, so you
have use a CVS snapshot:
"Note: Mahogany 0.64 requires the development snapshot of wxWindows
available from the link above (wxWindows-2.3.3-M). In particular,
don't use the official wxWindows 2.3.2 release as it unfortunately had
a bug which directly affected Mahogany. "
Well, it works, even though it is a "development snapshot". Compiling
C++ code is slow as molasses though, but I can't say whether or not
that's specific to 2.96 though. :-)
> 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.
If you read a bit further on that page I gave you the URL to, it tells
you what binary incompatibilities you can expect (only with C++, and
easy to fix). Other releases of gcc have the same problem, and what's
more, it doesn't affect Exim. If it did, then your advice would have
been worthwhile. As it is, it'll only confuse and hide the real
problem.
--
Regards,
Juha
C program run. C program crash. C programmer quit.
