13.1.1 GCC 2.96

Zum Hintergrund: Die Serie 2.95 des GCC ist der offiziell GNU-Release, und Version 2.95.3 ist die stabilste und fehlerfreieste aus dieser Serie. Wir haban niemals Probleme beobachten können, die auf den GCC 2.95.3 zurückzuführen waren. Beginnend mit RedHat Linux 7.0 begann Red Hat damit, eine stark veränderte CVS-Version des GCC mitzuliefern. Diese Version nannten sie 2.96. Red Hat hat diese Version aufgenommen, weil sie einen Compiler brauchten, der auf all ihren unterstützten Plattformen lief (welche auch IA64 und s390 einschloss), und weil der offizielle GCC 3.0 zu diesem Zeitpunkt noch nicht fertiggestellt war. Der Linuxdistributor Mandrake folgte bald darauf Red Hats Beispiel und lieferte ab Linux-Mandrake 8.0 ebenfalls den GCC 2.96 aus.

Die Aussagen zu dem Thema: Das GCC-Team hat jegliche Verbindung zu der Version 2.96 bestritten und dazu eine  offizielle Stellungnahme abgegeben. Viele Entwickler auf der ganzen Welt trafen auf Probleme mit dem GCC 2.96 und empfahlen deswegen andere Compilerversionen. Beispiele dafür sind  MySQL,  avifile und  Wine. Andere interessante Links sind der  Linux kernel news flash über den Kernel 2.4.17 und das  Voy-Forum. MPlayer war ebenfalls von vorrübergehenden Problemen betroffen, die sich alle lösten, sobald eine andere Version des GCC benutzt wurde. Viele Projekte begannen daraufhin damit, um einige der Probleme mit dem GCC 2.96 herumzuarbeiten, aber wir lehnten es ab, die Probleme zu beheben, die andere Leute durch vorschnelles Handeln verursacht hatten. Dazu kommt, dass einige dieser Workarounds zu Performanceeinbußen führten.

GCC 2.96 erlaubt keine |(Pipezeichen) in Assemblerkommentaren, weil er sowohl die Intel- als auch die AT&T- Assemblersyntax unterstützt und das |-Zeichen ein Symbol in der Intelvariante darstellt. Das Problem lag nun darin, dass der GCC kommentarlos den kompletten Assemblerblock ignoriert hat. Dieser Fehler wurde inzwischen angeblich behoben. GCC gibt eine Warnung aus, anstatt den kompletten Block einfach unter den Tisch fallen zu lassen.

Die Gegenwart: Red Hat behauptet, dass GCC Version 2.96-85 und neuer keine Fehler mehr enthalten. Das Verhalten dieser Version hat sich tatsächlich deutlich verbessert. Nichts desto trotz werden auf unseren Mailinglisten noch immer Probleme berichtet, die verschwinden, sobald ein anderer Compiler verwendet wird. Sei wie es ist, es ist inzwischen einfach nicht mehr wichtig. Hoffentlich löst eine gereifter GCC 3.x all dieses Problem ein für alle mal. Wenn du wirklich mit dem GCC 2.96 kompilieren möchtest, dann benutze die Option --disable-gcc-checking bei configure. Denk aber daran, dass du dann auf dich allein gestellt bist. Schick keine Fehlerberichte! Solltest du das doch tun, so wirst du nur von der Mailingliste verbannt, weil wir wirklich mehr Flamewars wegen des GCC 2.96 erlebt haben als nötig wär. Lass dieses Thema bitte ruhen.

Wenn du Probleme mit dem GCC 2.96 hast, so kannst du Pakete für die Version 2.96-85 auf Red Hats FTP- Server finden. Andererseits kannst du auch einfach die Pakete für die Version 3.0.4 benutzen, die Red Hat für Red Hat Linux 7.2 und neuer anbietet. Eine weitere Möglichkeit besteht darin, Pakete für gcc-3.2-10 herunterzuladen (inoffiziell, aber sie funktionieren trotzdem einwandfrei). Sie lassen sich neben dem GCC 2.96 installieren, den du bereits hast. MPlayer wird automatisch Version 3.2-10 finden und diesen GCC anstelle der Version 2.96 benutzen. Wenn du aus irgendeinem Grund die binären Pakete für den GCC nicht benutzen kannst oder willst, dann folgt hier eine kleine Anleitung, wie du den neuesten GCC kompilieren kannst:

1. Lade dir gcc-core-XXX.tar.gz von einem der  GCC-Mirrorseiten herunter, wobei XXX die Versionsnummer darstellt. Dieses Paket beinhaltet den kompletten C-Compiler und reicht für MPlayer aus. Wenn du darüber hinaus Unterstützung für C++, Java oder andere Features des GCC benötigst, dann ist gcc- XXX.tar.gz besser für dich geeignet.
2. Entpacke das Archiv:
   tar -xvzf gcc-core-XXX.tar.gz
3. Anders als die meisten Programme wird der GCC nicht innerhalb des Quelltextverzeichnisses gebaut, sondern er benötigt dafür ein spezielles Buildverzeichnis außerhalb des Quelltextbaumes. Erstell solch ein Verzeichnis mit
   mkdir gcc-build
4. Jetzt kannst du den GCC im Buildverzeichnis konfigurieren lassen aber das configure-Script liegt natürlich im Quelltextverzeichnis:
   cd gcc-build ../gcc-XXX/configure
5. Kompiliere GCC mit dem folgenden Kommando im Buildverzeichnis:
   make bootstrap
6. Jetzt kannst du (wenn du root bist) den GCC mit diesem Kommando installieren:
   make install

13.1.2 Vorkompilierte (binäre) Pakete

Früher enthielt MPlayer Teile des Quelltextes des OpenDivX- Projektes, welches es verbietet, vorkompilierte Pakete zu verteilen. Diese Codeabschnitte wurden aber in Version 0.90pre1 entfernt, und die letzte noch verbleibende Datei divx_vbr.c, die noch auf den OpenDivX-Quellen aufbaut, wurden von den Authoren unter die GPL gestellt (Version 0.90pre9). Du darfst jetzt also nach Herzenslust binäre Pakete bauen und verteilen.

Ein weiteres Hindernis für Binärpakete waren die bei der Kompilierung automatisch erkannten Optimierungsmöglichkeiten seitens der CPU-Architektur (MMX, 3DNOW etc.). MPlayer unterstützt inzwischen aber auch die Erkennung der CPU-Features beim Starten von MPlayer, wenn configure mit der Option --enable-runtime- cpudetection aufgerufen wurde. Diese Option ist standardmäßig deaktiviert, weil sie eine kleine negative Auswirkung auf die Geschwindigkeit mitbringt. Andererseits ist es mit ihr nun möglich, Binärpakete zu erstellen, die auf verschiedenen Mitgliedern der Intel-CPU-Familie beschleunigt laufen.

13.1.3 nVidia-Probleme

Uns missfällt die Tatsache, dass  nVidia nur binäre Treiber für XFree86 zur Verfügung stellt, die oft genug auch noch einige Fehler enthalten. Auf  mplayer-users sehen wir viele Fehlermeldungen, die mit diesen Closed-Source-Treibern zusammenhängen: über die allgemein schlechte Qualität der Treiber, über Instabilitäten und über den schlechten Support der Endbenutzer durch nVidia. Einige Beispiele dafür kannst du im  nVidia-Linux-Forum finden. Viele dieser Fälle sind wiederkehrende Probleme. nVidia hat letztens Kontakt mit uns aufgenommen und behauptet, dass ihre Treiber keine Fehler enthielten, sondern dass die Instabilitäten von schlechten AGP-Chips verursacht würden, und dass sie keinerlei Fehlerberichte von Nutzern erhalten hätten (wie z.B. die lila Linien). Wenn du also ein Problem mit deiner nVidia-Karte hast, dann solltest du auf jeden Fall die neuesten nVidia- Treiber ausprobieren und/oder ein neues Motherboard kaufen oder aber nVidia darum bitten, dass sie OpenSource-Treiber veröffentlichen. Wie dem auch sei - wenn du die binären nVidia-Treiber benutzt und Treiberprobleme auftreten, dann sei gewarnt, dass du von uns nur sehr wenig Hilfe erhalten wirst, weil wir da einfach nichts tun können, um dir zu helfen.