• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

GCC-4.0 macht Schwierigkeiten

Hallo,

ich habe auf PC1 SuSE-9.3 mit gcc-3.3.5
und auf PC2 SuSE-10.0 mit gcc-4.0.2

Auf PC2 habe ich wiederholt Schwierigkeiten,
ein Programm in Source zu compilieren:
gcover, kover, kbear, kcc, nftp, mplayer, ...

MPlayer sagt im make:
Checking for cc version ... 4.0.2, bad
Checking for gcc version ... 4.0.2, bad
Checking for gcc-3.4 version ... not found
Checking for gcc-3.3 version ... not found
Checking for gcc-3.2 version ... not found
Checking for gcc-3.1 version ... not found
Checking for gcc3 version ... not found
Checking for gcc-3.0 version ... not found
Checking for cc version ... 4.0.2, bad
*** Please downgrade/upgrade C compiler to version
gcc-2.95.x or gcc-3.x! ***
Error: Bad gcc version

GCC-4.x scheint Probleme zu machen. Welche
Lösungen gibt es?

1. Läuft ein (jedes) auf PC1 compiliertes Programm
auch auf PC2?

2. Schadet es dem SuSE-10.0 im Ganzen, wenn ich
auf gcc-3. downgraden würde?
Wenn, was alles gehört dann dazu?

3. Muss ich mir die gewaltige Arbeit machen, mein
System von SuSE-10.0 zurück auf SuSE-9.3 zu
reinstallieren?

4. Oder gibt es Tricks, mit den Schwierigkeiten
des GCC-4.x irgendwie doch fertig zu werden?
z.B. BEIDE Versionen auf dem PC2 zu haben?

Hilfe wird dankbar angenommen,

Werner.
 
WGz schrieb:
MPlayer sagt im make:
Checking for cc version ... 4.0.2, bad
Checking for gcc version ... 4.0.2, bad
Checking for gcc-3.4 version ... not found
Checking for gcc-3.3 version ... not found
Checking for gcc-3.2 version ... not found
Checking for gcc-3.1 version ... not found
Checking for gcc3 version ... not found
Checking for gcc-3.0 version ... not found
Checking for cc version ... 4.0.2, bad
*** Please downgrade/upgrade C compiler to version
gcc-2.95.x or gcc-3.x! ***
Error: Bad gcc version
Das ist definitiv nicht in Ordnung. Wenn der MPlayer mit dem GCC 4.0 nicht kompiliert, dann müssen die Autoren entweder ihren Code fixen oder Bug-Reports an das GCC-Team schicken. Den Compiler einfach im ./configure-Skript abzuweisen, ist keine akzeptable Lösung.
WGz schrieb:
1. Läuft ein (jedes) auf PC1 compiliertes Programm
auch auf PC2?
Ein ganz klares Nein! Wenn das Programm in C++ geschrieben ist und mit dem GCC 3.3 kompiliert wird, dann läuft es nicht auf einem System, dessen Bibliotheken mit dem GCC 4.0 kompiliert wurden. Wenn es nicht um C++ geht, kann es immer noch sein, dass die Bibliotheksversionen nicht zusammenpassen.
WGz schrieb:
2. Schadet es dem SuSE-10.0 im Ganzen, wenn ich
auf gcc-3. downgraden würde?
Wenn, was alles gehört dann dazu?
Ja, tut es, und dazu gehört gar nichts, weil es einfach nicht geht.
WGz schrieb:
3. Muss ich mir die gewaltige Arbeit machen, mein
System von SuSE-10.0 zurück auf SuSE-9.3 zu
reinstallieren?
Nein, das ist der falsche Weg. Der richtige Weg wäre, die zu kompilierende Software zu patchen, so dass sie doch mit dem GCC 4.0 kompiliert werden kann. Dafür gibt es keine allgemeingültige Anleitung, weil es bei jedem einzelnen Paket anders geht. Am einfachsten ist es, fertige Binärpakete anderer Leute zu nehmen oder in deren Quellpaketen nach den entsprechenden Patches zu suchen.
WGz schrieb:
4. Oder gibt es Tricks, mit den Schwierigkeiten
des GCC-4.x irgendwie doch fertig zu werden?
z.B. BEIDE Versionen auf dem PC2 zu haben?
Ja, gibt es. Für den MPlayer nimmst Du einfach ein fertiges Binärpaket von PackMan:

http://packman.links2linux.de/?action=128

Bei den anderen schaust Du einfach nach, ob es vielleicht anderswo Binärpakete gibt - kbear ist zum Beispiel garantiert bei SuSE im Lieferumfang - oder Du musst Dich eben auf die Suche nach entsprechenden Patches begeben.

Ich suche eigentlich immer auf drei Wegen nach Patches:

1. Fast jedes Projekt hat eine eigene Mailingliste, SourceForge-Projekte haben eine eigene Rubrik für Patches.

2. Auf http://rpm.pbone.net nach dem entspechenden Paket suchen, aus den angebotenen Distributionen eine raussuchen, die auch mit dem GCC 4.0 übersetzt wurde, beispielsweise Fedora Core 4 und dann rechts oben auf "Source RPM" klicken.

3. Beim Debian-Projekt nachschauen. Dazu nehme ich immer Google nach folgendem Muster:

http://www.google.de/search?q=paketname+site:packages.debian.org

Du musst natürlich den richtigen Paketnamen einsetzen. Beim Ergebnis dann unten rechts auf die Datei mit dem Muster "*.diff.gz" klicken.

Noch eine kleine Klarstellung, was die verschiedenen Compilerversionen angeht: Man kann durchaus mehrere Compiler installiert haben, aber das löst das Problem zumindest dann nicht, wenn C++ im Spiel ist. Nur der GCC 3.4 ist zum GCC 4.0 kompatibel, aber das nützt Dir nichts, weil der GCC 3.4 nie bei irgendeiner SuSE-Distribution dabei war.

Auf der OpenSuSE-Mailingliste meine ich nachgelesen zu haben, dass jemand den GCC 3.4 für SuSE 10.0 verpacken wollte, aber das Ergebnis konnte ich bisher nirgends finden.
 
WGz schrieb:
Checking for cc version ... 4.0.2, bad
*** Please downgrade/upgrade C compiler to version
gcc-2.95.x or gcc-3.x! ***
Error: Bad gcc version

Code:
./configure --disable-gcc-checking ...
dann kommt eine Warnung und nach Tastendruck gehts weiter.
MP compiliert auch mit gcc4.*
 
traffic schrieb:
WGz schrieb:
1. Läuft ein (jedes) auf PC1 compiliertes Programm
auch auf PC2?
Ein ganz klares Nein!

Dem muss ich ganz klar widersprechen! Möglicherweise hängt das auch von den Sourcen ab, aber ich habe mehrere auf SuSE 9.3 und somit mit dem gcc 3.2.x erstellte RPMs hier erfolgreich eingesetzt.

Die erste Kalva-Installation nach dem Upgrade von 9.3 auf 10.0 war so ein Paket. Es lief völlig problemlos. Die libdvdcss habe ich auch nicht neu kompiliert. Ich habe auch hier einfach das unter SuSE 9.3 erstellte RPM in der SUSE 10.0 installiert und sie funktioniert ebenfalls problemlos.

traffic schrieb:
WGz schrieb:
2. Schadet es dem SuSE-10.0 im Ganzen, wenn ich
auf gcc-3. downgraden würde?
Wenn, was alles gehört dann dazu?
Ja, tut es, und dazu gehört gar nichts, weil es einfach nicht geht.

Na ja, sag niemals nie... Aber das ist was für absolut hartgesottene und sehr masochistisch veranlagte Gurus. Die Mühe ist es wirklich nicht wert. Faktisch gebe ich Dir da schon recht.
 
taki schrieb:
Dem muss ich ganz klar widersprechen! Möglicherweise hängt das auch von den Sourcen ab, aber ich habe mehrere auf SuSE 9.3 und somit mit dem gcc 3.2.x erstellte RPMs hier erfolgreich eingesetzt.
es hängt von den Libs ab und mit welchem Compiler die gebaut sind.
 
TeXpert schrieb:
taki schrieb:
Dem muss ich ganz klar widersprechen! Möglicherweise hängt das auch von den Sourcen ab, aber ich habe mehrere auf SuSE 9.3 und somit mit dem gcc 3.2.x erstellte RPMs hier erfolgreich eingesetzt.
es hängt von den Libs ab und mit welchem Compiler die gebaut sind.

Schon klar.

Die Bibliothek ist abwärtskompatibel. Mit älterem gcc übersetzte und gelinkte Binärprogramme laufen auch auf dem System, welches gegen die Standard-C++ Bibliothek des neueren gcc gelinkt wurde.

Konkret: Kalva und auch libdvdcss in SuSE 9.3 mit gcc 3.2 übersetzt, gelinkt und in ein RPM gepackt läuft auch auf SUSE 10.0.

Umgekehrt wird es aber eher nicht funktionieren.
 
etwas komplexer ist das schon :) ich möchte hier einfach mal auf einen Post in Debian-Devel-announce verweisen: http://lists.debian.org/debian-devel-announce/2005/07/msg00001.html

da geht es im Detail um die letzte ABI-Transition in Debian bzgl. gcc 4 und gcc 3 das erhellt das evtl. noch etwas mehr
 
taki schrieb:
Dem muss ich ganz klar widersprechen!
Sorry, wenn es Pakete gibt, die auf den ersten Blick doch problemlos zu funktionieren scheinen, dann ist das reiner Zufall. Und es bedeutet auch nicht, dass sie wirklich funktionieren - sie können auch erst bei bestimmten Ereignissen auffällig werden.

Wegen der Sache mit der ABI-Änderung hat TeXpert ja schon einen Link genannt, aus dem hervorgeht, dass man das, wenn man einigermaßen sicherstellen will, dass alles läuft, nicht machen kann.
taki schrieb:
Na ja, sag niemals nie...
Mann kann den GCC 3.4 aus den Sourcen bauen, aber das ist wirklich alles andere als Trivial und vor allem braucht man dafür schnelle Hardware und viel Zeit. Auf meiner Hardware würde es sicherlich einen Tag dauern.

Außerdem sollte man wissen, dass, wenn man den GCC 3.4 mit "./configure && make && make install" installiert, ein Symlink darauf als "/usr/local/bin/gcc" installiert wird mit der Konsequenz, dass der GCC 3.4 zunächst mal zum Standardcompiler wird und von allen Paketen benutzt wird, sofern man es nicht ausdrücklich anders angibt oder den Symlink wieder entfernt. Ich würde nicht sagen, dass der Aufwand sich lohnt.

Der GCC 3.4 als RPM von suser-gbv ist übrigens immer noch nicht da, stattdessen ist da jetzt ein Snapshot vom GCC 4.1. Daraus entnehme ich, dass suser-gbv es sich anders überlegt hat und doch kein RPM machen will.
 
traffic schrieb:
taki schrieb:
Dem muss ich ganz klar widersprechen!
Sorry, wenn es Pakete gibt, die auf den ersten Blick doch problemlos zu funktionieren scheinen, dann ist das reiner Zufall. Und es bedeutet auch nicht, dass sie wirklich funktionieren - sie können auch erst bei bestimmten Ereignissen auffällig werden.

Dass Kalva funktioniert und keine Probleme macht, kann ich wohl schon recht gut beurteilen :wink: Und welche Bibliotheken da alle mit spielen, kann ich auch ganz gut beurteilen, das kannst Du mir wohl glauben...

Bei der libdvdcss kann es auch keinen Zweifel geben.
 
Oben