gcc v3.2 vs v3.3
Andre Homberg
ich habe hier suse8.2-prof installiert. dieses liefert ein pre-realease des
gcc-v3.3 mit. einige programme lassen sich nicht einwandfrei mit diesem
compiler durchcompilieren (auf suse8.1 mit gcc 3.2 gabs keinerlei
probleme).
meine frage ist jetzt ob der gcc-v3.2 binaerkompatibel zu gcc-v3.3 ist. wo
kann ich dazu naehere infos finden?
wenn ja, kann ich einfach das srpm von suse-8.1 neu bauen (rpm -ba
gcc.srpm)? Dieses moechte ich dann nachdem der gcc-3.3 compiler
deinstalliert wurde per "rpm -i gcc-3.2.rpm" installieren.
gruss,
andre
Rainer Weikusat
> meine frage ist jetzt ob der gcc-v3.2 binaerkompatibel zu gcc-v3.3 ist. wo
> kann ich dazu naehere infos finden?
'info gcc'
> wenn ja, kann ich einfach das srpm von suse-8.1 neu bauen (rpm -ba
> gcc.srpm)? Dieses moechte ich dann nachdem der gcc-3.3 compiler
> deinstalliert wurde per "rpm -i gcc-3.2.rpm" installieren.
Was spricht dagegen, die Originalsourcen zu verwenden? Ich habe hier
mehrere 3.2.? auf unterschiedlichen Systemen (größtenteils aus
Neugier) und typischerweise ist das weniger Aufwand, als rpm's zu
bauen und ich würde bezweiflen, daß es eine besonders gute Idee ist, den
Systemcompiler zu ersetzen (egal, wie kaputt der vielleicht sein mag).
Andre Homberg
> Was spricht dagegen, die Originalsourcen zu verwenden? Ich habe hier
> mehrere 3.2.? auf unterschiedlichen Systemen (größtenteils aus
> Neugier) und typischerweise ist das weniger Aufwand, als rpm's zu
> bauen und ich würde bezweiflen, daß es eine besonders gute Idee ist, den
> Systemcompiler zu ersetzen (egal, wie kaputt der vielleicht sein mag).
hi,
oki, ansich faend ichs auch besser die original gcc3.2.x-sourcen zu
compilierern, und unter /usr/local zu installieren.
allerdings weis ich nicht ganz genau wie dabei vorzugehen ist, wenn dann
spaeter das program xyz compiliert&installieren werden muss. wie kann ich
sicher sein das die Makefiles der programme dann den gcc unter
"/usr/local/" verwenden?
thnxs & gruss,
andre
Andre Homberg
kleiner nachtrag - wie kann ich sicher ssein da die richtigen liberays und
header-files verwendet werden?
gruss,
andre
Rainer Weikusat
> kleiner nachtrag - wie kann ich sicher ssein da die richtigen liberays und
> header-files verwendet werden?
Den richtigen gcc bekommt man durch einen geeignet gesetzen PATH und
die libraries und headers stehen im spec-file, das dazu gehört:
[rw@dawn]:~ $gcc -v
Reading specs from /usr/local/bin/../lib/gcc-lib/sparc-sun-solaris2.8/3.2/specs
Configured with: ./configure --prefix=/usr/local/stow/gcc-3.2 --prefix=/usr/local/stow/gcc-3.2 --disable-nls
Thread model: posix
gcc version 3.2
[rw@dawn]:~ $/opt/sfw/bin/gcc -v
Reading specs from /opt/sfw/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/specs
gcc version 2.95.3 20010315 (release)
... und natürlich:
[rw@dawn]:~ $/usr/ucb/cc.sun
/usr/ucb/cc: language optional software package not installed
[SCNR]
BTW, ich würde über die Benutzung von 'stow' wenigstens mal
nachdenken, das mögen zwar eine Menge Leute aus diversen Gründen
nicht, aber meiner Meinung nach vereinfacht es die Handhabung
selbstübersetzter Software (in ggf unterschiedlichen Versionen)
erheblich.
Andreas Jaeger
> hi,
> ich habe hier suse8.2-prof installiert. dieses liefert ein pre-realease des
> gcc-v3.3 mit. einige programme lassen sich nicht einwandfrei mit diesem
> compiler durchcompilieren (auf suse8.1 mit gcc 3.2 gabs keinerlei
> probleme).
Was für Probleme hast Du? Der GCC 3.3 hat einige Sachen "deprecated",
die in GCC 3.2 Warnungen ausgaben.
> meine frage ist jetzt ob der gcc-v3.2 binaerkompatibel zu gcc-v3.3 ist. wo
> kann ich dazu naehere infos finden?
Er ist binärkompatibel. Wenn Du eine 8.1 hast, und so Probleme,
installiere doch einfach die RPMs von der 8.1...
> wenn ja, kann ich einfach das srpm von suse-8.1 neu bauen (rpm -ba
> gcc.srpm)? Dieses moechte ich dann nachdem der gcc-3.3 compiler
> deinstalliert wurde per "rpm -i gcc-3.2.rpm" installieren.
Einziges Problem könnte sein, daß libstdc++ zusätzliche Symbole hat,
die der 3.2 nicht hat - aber das ist in SuSEs 3.3 nicht der Fall, also
sollte es gehen,
Andreas
--
Andreas Jaeger
SuSE Labs a...@suse.de
private a...@arthur.inka.de
http://www.suse.de/~aj
Andre Homberg
>Den richtigen gcc bekommt man durch einen geeignet gesetzen PATH und
>die libraries und headers stehen im spec-file, das dazu gehört:
darauf haette ich auch selbst kommen koennen... irgentwie hatte ich das
mitder glibc verwechselt ;-)
thnxs nochmal,
gruss,
andre
Walter Harms
>> gcc.srpm)? Dieses moechte ich dann nachdem der gcc-3.3 compiler
>> deinstalliert wurde per "rpm -i gcc-3.2.rpm" installieren.
>Einziges Problem könnte sein, daß libstdc++ zusätzliche Symbole hat,
>die der 3.2 nicht hat - aber das ist in SuSEs 3.3 nicht der Fall, also
>sollte es gehen,
>Andreas
>--
> Andreas Jaeger
> SuSE Labs a...@suse.de
> private a...@arthur.inka.de
> http://www.suse.de/~aj
Es gibt definitiv unterschiede ich habe ein programm das mit suse8.1 compiliert
(gcc-3.2) aber mit 8.2 nicht weil eine library "errno" nicht mehr kennt.
Ich dachte bisher das sei eher ein linke problem.
walter
--
Rainer Weikusat
> Andreas Jaeger <a...@arthur.inka.de> writes:
>>Einziges Problem könnte sein, daß libstdc++ zusätzliche Symbole hat,
>>die der 3.2 nicht hat - aber das ist in SuSEs 3.3 nicht der Fall, also
>>sollte es gehen,
>
> (gcc-3.2) aber mit 8.2 nicht weil eine library "errno" nicht mehr
> kennt.
Das hört sich sehr unwahrscheinlich an.
Bodo Thiesen
> Es gibt definitiv unterschiede ich habe ein programm das mit suse8.1
> compiliert (gcc-3.2) aber mit 8.2 nicht weil eine library "errno" nicht
> mehr kennt. Ich dachte bisher das sei eher ein linke problem.
#include <errno.h>
Das Dumme ist, daß manche Header-Dateien andere mit einbinden, und dadurch
das Fehlen einzelner Header schlicht nicht auffällt. Annahme z.B. stdio.h
habe in 3.2 noch errno.h eingebunden, bei 3.3 aber nicht mehr. Wat nu?
Richtig: "undefined symbol `errno'". Also einfach den Quelltext
korrigieren, ein Patch an den Autor, und dann funzt das ganze wieder.
--
Gruß, Bodo [DE: http://piology.org/ILOVEYOU-Signature-FAQ.html]
@@@@@ GEGEN TCG aka. TCPA: @@@@@ [DE: http://www.againsttcpa.com]
Wer fragt ist nur drei Minuten Dumm.
Juergen Ilse
Walter Harms <u17...@grossglockner.informatik.uni-oldenburg.de> wrote:
[ gcc3.2.x und gcc3.3 ]
> Es gibt definitiv unterschiede ich habe ein programm das mit suse8.1
> compiliert (gcc-3.2) aber mit 8.2 nicht weil eine library "errno" nicht
> mehr kennt.
Was heisst "weil eine library errno nicht mehr kennt"?
Bekommst du bereits beim comilieren einen Fehler oder bereits
beim linken? Ein beliebter Fehler in vielen aelteren Sourcen
ist es, wenn statt <errno.h> einzubinden einfach eine Variable
mit "external linkage" namen "errno" deklariert wird. "errno"
muss aber laut C-Standard keine Variable sein sondern kann auch
als Macro in <errno.h> definiert sein (z.B. bei multithreading-
Programmen, aber das kann auch generell so sein).
Wenn in einem solchen Fall einfach
extern int errno;
statt
#include <errno.h>
im Quelltext steht, wird sich der erzeugte code nicht mehr linken
lassen, weil das Symbol "errno" nirgends gefunden wird ...
Uebrigens fordert (laut einem Kommentar in den Solaris8 System-Header-Files)
ANSI-C++ sogar, dass errno ein Macro ist (und deswegen findet sich dort
dann ein so seltsames Konstrukt wie:
/* ANSI C++ requires that errno be a macro */
#if __cplusplus >= 199711L
#define errno errno
#endif
Was nun wirklich etwas seltsam anmutet ...
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
[ Alfred Schulze ueber Norton Internet Security in dcsf ]
Es ist ja eigentlich auch nicht zum runterbekommen gemacht.
Normalerweise gehoert es genau wie ein Windows ein Leben
lang auf den Computer.
Felix von Leitner
> Es gibt definitiv unterschiede ich habe ein programm das mit suse8.1 compiliert
> (gcc-3.2) aber mit 8.2 nicht weil eine library "errno" nicht mehr kennt.
> Ich dachte bisher das sei eher ein linke problem.
Das ist ein glibc-Problem.
Du hast gerade am eigenen Leib erfahren, wieso man von Code von Herrn
Drepper weiträumig Abstand halten will.
Felix
Rainer Weikusat
Ich könnte da noch ein paar Beispiele beisteuern :->>
Andreas Jaeger
Das ist ein Problem der glibc, glibc exportiert errno nicht mehr, Du
mußt wirklich
#include <errno.h> machen.
8.2 hat glibc 2.3.2, 8.1 hat 2.2.5 - und das ist der relevante
Unterschied hier,
Andre Homberg
>
> Was für Probleme hast Du? Der GCC 3.3 hat einige Sachen "deprecated",
> die in GCC 3.2 Warnungen ausgaben.
hi,
ich hatte probleme beim compilieren des mplayer-v0.90rc4 (beim aktuellen
mplayer-0.90 gehts jetzt).
zz habe ich das problem das sich freetype-1.3.1 nicht kompilieren laesst.
nach einer gewissen zeit bricht das MakeScript mit folgender Meldung ab:
gcc -c -I.
-I/var/tmp/src-build/freetype-1.3.1/Build/freetype-1.3.1/test/arch/unix/../..
-I..
-I/var/tmp/src-build/freetype-1.3.1/Build/freetype-1.3.1/test/arch/unix/../../
../lib
-I/var/tmp/src-build/freetype-1.3.1/Build/freetype-1.3.1/test/arch/unix/../../
../lib/extend -march=i686 -O3 -I/usr/X11R6/include -Wall -pedantic -ansi
-DX11 -DLOCALEDIR='"/usr/local/share/locale"' ftdump.c
ftdump.c:172:29: pasting "." and "glyph_object" does not give a valid
preprocessing token
ftdump.c:182:31: pasting "." and "first_instance" does not give a valid
preprocessing token
ftdump.c:191:32: pasting "." and "second_instance" does not give a valid
preprocessing token
ftdump.c:201:62: pasting "." and "face_object" does not give a valid
preprocessing token
ftdump.c:202:62: pasting "." and "glyph_object" does not give a valid
preprocessing token
ftdump.c:203:62: pasting "." and "second_instance" does not give a valid
preprocessing token
ftdump.c: In function `Print_SBits':
ftdump.c:545: warning: comparison between signed and unsigned
ftdump.c:863:33: pasting "." and "initial_overhead" does not give a valid
preprocessing token
ftdump.c:882:28: pasting "." and "face_object" does not give a valid
preprocessing token
make[1]: *** [ftdump.o] Fehler 1
make[1]: Leaving directory
`/var/tmp/src-build/freetype-1.3.1/Build/freetype-1.3.1/test'
make: *** [tttest] Fehler 2
wie ich bereits sagte liess sich das programm unter suse8.1 einwanfrei
compilieren.
irgentwie fangen diese ganzen glibc/gcc-probleme an zu nerven. angeblich
soll der gcc3.3 probleme beim kernel-compilieren verursachen, weil er keine
zweizeiligen strings akzeptiert.
warum muessen staendig interna des compilers/glibc-bibiothek angepasst
werden?
und warum muessen die binarys am ende mit jeder gcc/glibc-version
uncompatibel zu den vorgaenger-versionen sein?
ich mache den vergleich zu ms nicht gerne. aber dort ist ein unter
win95-compiliertes programm immernoch unter winXp lauffaehig. ueber 6-7
jahre hinweg hat es ms geschafft abwaertskompatibel zu bleiben.
wenn schon nicht die binary-kompatibilitaet gewahrt werden kann, dann
sollten es wenigstens aufder source-ebene keinerlei probleme geben
x-beliebeige programme ueber jahre hinweg zu kompilieren....
gruss & thnxs,
andre
Juergen Ilse
Andre Homberg <hom...@fourmart.de> wrote:
> irgentwie fangen diese ganzen glibc/gcc-probleme an zu nerven. angeblich
> soll der gcc3.3 probleme beim kernel-compilieren verursachen, weil er keine
> zweizeiligen strings akzeptiert.
Wenn der Code das voraussetzt, ist er genaugenommen fehlerhaft (bzw. er
setzt etwas voraus, was nirgends als Eigenschaft des Compilers garantiert
wird oder wurde, im Grunde genommen liess sich das bisher nur "zufaellig"
uebersetzen). Man sollte in solchen Faellen den code anpassen und nicht
den Compiler ...
> warum muessen staendig interna des compilers/glibc-bibiothek angepasst
> werden?
Es werden IMHO keine Aenderungen durchgefuehrt, die dem Standard der
jeweiligen Sprache widersprechen wuerden. Wenn irgendwelcher Code
Eigenschaften des Compilers voraussetzt, die weder in der Doku des
Compilers noch im Standard der jeweiligen Sprache garantiert werden,
ist genau genommen der code fehlerhaft, nicht der Compiler. Abhilfe
sollte man dadurch schaffen, dass man den code korrigiert, nicht
dadurch, dass man den Compiler an die ehemals vorhandenen undokumen-
tierten Eigenschaften frueherer Versionen anpasst.
> und warum muessen die binarys am ende mit jeder gcc/glibc-version
> uncompatibel zu den vorgaenger-versionen sein?
Das ist seit laengerer Zeit eigentlich fast ausschliesslich bei C++
vorgekommen (und da lag es daran, dass man das binary-API an den
mittlerweile verfuegbaren Standard angepasst hat, um Code, der mit
unterschiedlichen aktuellen Compilern uebersetzt wurde gegeneinander
linken zu koennen, fuer x86 z.B. Intels Compiler und gcc ...).
> ich mache den vergleich zu ms nicht gerne. aber dort ist ein unter
> win95-compiliertes programm immernoch unter winXp lauffaehig. ueber 6-7
> jahre hinweg hat es ms geschafft abwaertskompatibel zu bleiben.
Das kannst du unter Linux noch immer haben, wenn du jeweils die dazu
gehoerenden shared libraries im System vorhaeltst, das System so kon-
figurierst, dass die fraglichen Programme *ihre* shared libraries auch
finden oder indem du die Programme schlicht statisch linkst ...
Das furchtbare Chaos der DLL-Versionen bei windows wirst du dir nicht
wirklich wuenschen wollen, oder etwa doch?
> wenn schon nicht die binary-kompatibilitaet gewahrt werden kann, dann
> sollten es wenigstens aufder source-ebene keinerlei probleme geben
> x-beliebeige programme ueber jahre hinweg zu kompilieren....
Bei "Standard-konformen Programmen" gibt es da auch i.d.R. keine
Probleme. Wenn allerdings bestimmte undokumentierte Eigenschaften des
Compilers oder Praeprozessors oder Linkers oder ... vorausgesetzt werden,
die sich ggfs. in spaeteren Versionen mal geaendert haben, dann ist das
in aller Regel ein Problem der Sourcen (wenn man sie nicht als Fehlerhaft
bezeichnen will, muss man zumindest "unportabel" zugeben ...).
Andre Homberg
> Wenn der Code das voraussetzt, ist er genaugenommen fehlerhaft (bzw. er
> setzt etwas voraus, was nirgends als Eigenschaft des Compilers garantiert
> wird oder wurde, im Grunde genommen liess sich das bisher nur "zufaellig"
> uebersetzen). Man sollte in solchen Faellen den code anpassen und nicht
> den Compiler ...
>
hi,
da stimm ich dir natuerlich voll zu. weshalb laesst dann der gcc ueberhaupt
solche undokumentierten 'funktionen' zu?
thnxs & gruss,
andre
King Leo - Martin Oberzalek
> Hallo,
>
> Walter Harms <u17...@grossglockner.informatik.uni-oldenburg.de> wrote:
> [ gcc3.2.x und gcc3.3 ]
>> Es gibt definitiv unterschiede ich habe ein programm das mit suse8.1
>> compiliert (gcc-3.2) aber mit 8.2 nicht weil eine library "errno" nicht
>> mehr kennt.
> Ein beliebter Fehler in vielen aelteren Sourcen
> ist es, wenn statt <errno.h> einzubinden einfach eine Variable
> mit "external linkage" namen "errno" deklariert wird.
Also ich mach das immer so:
#include <errno.h>
#ifndef errno
extern int errno
#endif
Denn es gab da irgendwo mal eine "libc" in der in <errno.h> errno weder als
ein Makro, noch als Variable deklariert war (cyqwin eventuell.)
Ach ja:
man errno
| SYNOPSIS
| #include <errno.h>
|
| extern int errno;
Gruß, Martin!
--
Forget GNU Stow, use the power of XStow: http://xstow.sourceforge.net
Rainer Weikusat
> Andre Homberg <hom...@fourmart.de> wrote:
>> irgentwie fangen diese ganzen glibc/gcc-probleme an zu nerven. angeblich
>> soll der gcc3.3 probleme beim kernel-compilieren verursachen, weil er keine
>> zweizeiligen strings akzeptiert.
>
> Wenn der Code das voraussetzt, ist er genaugenommen fehlerhaft
'Genaugenommen' handelt es sich um eine tradtionelle gcc-Erweiterung
die als solche dokumentiert ist und mittlerweile (3.2) 'deprecated'.
Bodo Thiesen
> da stimm ich dir natuerlich voll zu. weshalb laesst dann der gcc
> ueberhaupt solche undokumentierten 'funktionen' zu?
Weil die Programmierer nicht auf jeden Sch*** getestet haben.
Bzw. einige dieser Funktionen "gewünscht" waren...
Der GCC ist halt kein ISO-C-Checker (und das war auch nie beabsichtigt -
auch wenn -ansi -pedantic schon etwas in diese Richtung geht).
Juergen Ilse
Es handelt sich nicht um eine "undokumentierte Funktion". Wenn in den
Sourcen steht "extern int errno" geht der Compiler (gemaess dem, was
in dieser Deklaration steht) davon aus, dass es irgendwo (in einem
anderen object-file oder in einer Library, die dazu gelinkt wird)
auch eine Variable mit "external linkage" und dem Namen "errno"
existiert. Das ist aber nicht der Fall, weil errno ein Macro ist,
dessen Definition nicht mit eingebunden wurde. Der Compiler wurde
bzgl "errno" schlicht "belogen", also hatte er zur Compile-Zeit
keine Chance, den Fehler zu entdecken.
Auf manchen Systemen haette das sogar so hingehauen, weil eben manchmal
tatsaechlich "errno" nur ein "extern int" ist, aber das muss eben nicht
immer so sein (bei hinreichend neuen glibc Versionen ist es z.B. nicht
der Fall). Da man dem Compiler falsche Deklarationen vorgesetzt hat,
hat man ihm auch noch die Moeglichkeit genommen, den Fehler zu entdecken.
Peter J. Holzer
> Juergen Ilse wrote:
>> Walter Harms <u17...@grossglockner.informatik.uni-oldenburg.de> wrote:
>> [ gcc3.2.x und gcc3.3 ]
>>> Es gibt definitiv unterschiede ich habe ein programm das mit suse8.1
>>> compiliert (gcc-3.2) aber mit 8.2 nicht weil eine library "errno" nicht
>>> mehr kennt.
>
>> Ein beliebter Fehler in vielen aelteren Sourcen
>> ist es, wenn statt <errno.h> einzubinden einfach eine Variable
>> mit "external linkage" namen "errno" deklariert wird.
Ja:
ISO/IEC:9899:1999, §7.5:
| if [...] a program defines an identifier with the name errno, the
| behavior is undefined.
> Also ich mach das immer so:
>
> #include <errno.h>
>
> #ifndef errno
> extern int errno
> #endif
Aber nicht in jedem Source-File, das errno verwendet, sondern in einem
eigenen Include-File, hoffe ich?
> Ach ja:
>
> man errno
>
>| SYNOPSIS
>| #include <errno.h>
>|
>| extern int errno;
Das heißt aber nicht, dass Du in Deinem Source-Code "extern int errno;"
deklarieren sollst, sondern dass errno in <errno.h> als "extern int
errno;" oder äquivalent deklariert ist.
hp
--
_ | Peter J. Holzer | Latein ist das humanoide Äquivalent
|_|_) | Sysadmin WSR | zu Fortran.
| | | h...@hjp.at |
__/ | http://www.hjp.at/ | -- Alexander Bartolich in at.linux
Andreas Jaeger
> Andreas Jaeger wrote:
>>
>> Was für Probleme hast Du? Der GCC 3.3 hat einige Sachen "deprecated",
>> die in GCC 3.2 Warnungen ausgaben.
>
> hi,
> ich hatte probleme beim compilieren des mplayer-v0.90rc4 (beim aktuellen
> mplayer-0.90 gehts jetzt).
> zz habe ich das problem das sich freetype-1.3.1 nicht kompilieren laesst.
> nach einer gewissen zeit bricht das MakeScript mit folgender Meldung ab:
>
> gcc -c -I.
> -I/var/tmp/src-build/freetype-1.3.1/Build/freetype-1.3.1/test/arch/unix/../..
> -I..
> -I/var/tmp/src-build/freetype-1.3.1/Build/freetype-1.3.1/test/arch/unix/../../
> ../lib
> -I/var/tmp/src-build/freetype-1.3.1/Build/freetype-1.3.1/test/arch/unix/../../
> ../lib/extend -march=i686 -O3 -I/usr/X11R6/include -Wall -pedantic -ansi
> -DX11 -DLOCALEDIR='"/usr/local/share/locale"' ftdump.c
> ftdump.c:172:29: pasting "." and "glyph_object" does not give a valid
> preprocessing token
Das sind Änderungen für den C Standard, der Preprocessor hat das
vorher akzeptiert, aber es entspricht nicht dem Standard.
Da ist wohl ein extra ## drin, einfach rausnehmen und es sollte klappen.
Und dafür gab's mit GCC 3.2 eine Warnung...
> warum muessen staendig interna des compilers/glibc-bibiothek angepasst
> werden?
Frag auf den Entwicklerlisten...
> und warum muessen die binarys am ende mit jeder gcc/glibc-version
> uncompatibel zu den vorgaenger-versionen sein?
> ich mache den vergleich zu ms nicht gerne. aber dort ist ein unter
> win95-compiliertes programm immernoch unter winXp lauffaehig. ueber 6-7
> jahre hinweg hat es ms geschafft abwaertskompatibel zu bleiben.
Das geht auch unter LInux, alte Programme laufen weiterhin.
> wenn schon nicht die binary-kompatibilitaet gewahrt werden kann, dann
> sollten es wenigstens aufder source-ebene keinerlei probleme geben
> x-beliebeige programme ueber jahre hinweg zu kompilieren....