Daniel Jensen wrote:
> Hej med jer alle sammen ;)
> Jeg kører redhat 7.1 med redhat's compiler gcc version 2.96. Jeg er løbet
> ind i lidt problemer med at kompilere visse ting med denne compiler da den
> åbenbart er en udviklingscompiler og vissse linux projekter understøtter
> den simpelthen ikke, eksempelvis dette uddrag fra
>
http://avifile.sourceforge.com
> :
>
> During last few weeks two major Linux distribution producers - Mandrake
> and RedHat - have released new versions of their distributions.
> Unfortunately, for reasons only known to their marketing strategists,
> these distributions include unstable development versions of C++ compiler
> - gcc 2.96.
Jeg er efterhånden dødtræt af at høre om "RedHat's buggy compiler" eller
"RedHat's udviklings compiler".
Selvfølgelig er der fejl i RH compileren. Men der er langt _færre_ fejl i
RHs compiler, end der er i gcc 2.95. De fejl, som folk oplever, er fejl i
deres _egne_ programmer. RH's compiler opfylder C++ standarden langt bedre
end gcc 2.95.
Jeg kan fortælle, at jeg regelmæssig kompilerer KDE (som er en helt ernorm
mængde C++ kode). Uden det mindste problem !
Hvad angår "reasons only known to their marketing strategists", så må jeg
åbenbart være havnet i Red Hat's markeringsafdeling, for jeg ved skam godt,
hvorfor de lavede den compiler: Det var et ønske fra deres _kunder_ ! De
var ved at være trætte af at vente på gcc 3.0. På det tidspunkt, hvor Red
Hat udsendte deres compiler, var der gået halvandet år uden en officiel
gcc release. I dag - endnu et halvt år senere - er gcc 3.0 kommet og den
er mildest talt ikke i stand, der gør det muligt at sætte den i produktion.
Her er hvad en af gcc steering committee medlemmerne fandt i en test af
gcc 3.0 :
> Well, here I have to step up again, I'm afraid. If you look at
>
http://gcc.gnu.org/ml/gcc/2001-07/msg01376.html
> you'll see that C++ projects heavily relying on STL apparently
> simply cannot use GCC 3.0.
>
> GCC 2.95 GCC 3.0
> Compile time Binary size Compile time Binary Size
> -O0 6:19 3915128 8:20 4159780
> -O1 4:20 4203480 11:40 4829732
> -O2 5:56 4209368 14:09 4862532
> -O3 5:47 4221464 32:04 6166052
Link:
http://gcc.gnu.org/ml/gcc/2001-07/msg01421.html
Plus at gcc 3.0 crasher for et godt ord og i nogle tilfælde genererer
forkert kode...
Jeg har en anden link, som du bør læse:
http://www.bero.org/gcc296.html .
Jeg vil også gerne citere en AC fra slashdot (som jeg gætter på er en af
udviklerne af gcc):
o gcc 2.96 is actually more standards compliant than any other version of
gcc released at the time Red Hat made this decision (3.0 is even more
compliant, but not as stable) yet). It may not be "standards compliant"
as in "what most others are shipping", but 2.96 is almost fully ISO C99
and ISO C++ 98 compliant, unlike any previous version of gcc.
o 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.
o gcc 2.96 generates better, more optimized code.
o gcc 2.96 supports all architectures Red Hat is currently supporting,
including ia64. No other compiler can do this. Having to maintain different
compilers for every different architecture is a development (find a bug,
then fix it 4 times), QA and support nightmare.
o The binary incompatibility issues are not as bad as some people and
companies make you believe. First of all, they affect dynamically linked
C++ code only. If you don't use C++, you aren't affected. If you use C++
and link statically, you aren't affected. If you don't mind depending on
a current glibc, you might also want to link statically to c++ libraries
while linking dynamically to glibc and other C libraries you're using:
g++ -o test test.cc -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic (Thanks to Pavel
Roskin for pointing this out) Second, the same issues appear with every
major release of gcc so far. gcc 2.7.x C++ is not binary compatible with
gcc 2.8.x. gcc 2.8.x C++ is not binary compatible with egcs 1.0.x. egcs
1.0.x C++ is not binary compatible with egcs 1.1.x. egcs 1.1.x C++ is not
binary compatible with gcc 2.95. gcc 2.95 C++ is not binary compatible with
gcc 3.0. Besides, it can easily be circumvented. Either link statically, or
simply distribute libstdc++ with your program and install it if necessary.
Since it has a different soname, it can coexist with other libstdc++
versions without causing any problems. Red Hat Linux 7 also happens to be
the first Linux distributions using the current version of glibc, 2.2.x.
This update is not binary compatible with older distributions either (unless
you update glibc - there's nothing that prevents you from updating libstdc++
at the same time), so complaining about gcc's new C++ ABI breaking binary
compatibility is pointless. If you want to distribute something binary-only,
link it statically and it will run everywhere. Someone has to be the first
to take a step like this. If nobody dared to make a change because nobody
else is doing it, we'd all still be using gcc 1.0, COBOL or ALGOL. No wait,
all of those were new at some point...
o 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. A C or C++ compiler that
doesn't speak the standardized C language is a bug, not a feature. In the
initial version of gcc 2.96, there were a couple of other bugs. All known
ones have been fixed in the version from updates - and the version that is
in the current beta version of Red Hat Linux. The bugs in the initial
version don't make the whole compiler broken, though. There has never been
a 100% bug free compiler, or any other 100% bug free non-trivial program.
The current version can be downloaded here.
o gcc 3.0, the current "stable" release (released quite some time after Red
Hat released gcc 2.96-RH), fixes some problems, but introduces many others
- for example, gcc 3.0 can't compile KDE 2.2 beta 1 correctly. Until the
first set of 3.0 updates is released, I still claim 2.96 is the best
compiler yet.
[...]
> Man kan kun stille sig undrende overfor hvorfor en distribution som redhat
> vælger at ødelægge standarden ved at inkludere deres egen compiler, og
> håbe på at de i version 7.2 bruger gcc3.....
RedHat 7.2 bruger ikke gcc 3.0 (og heller ikke RH 7.3, hvis der kommer en
sådan).
Hvis du har fulgt med så langt, så kan du bruge kgcc (egcs-2.91.66) i stedet.
Du skal nok ind i makefilen og sætte CC=kgcc .
-Claus