Aufschrei der Entwickler GCC 2.96 Der Hintergrund: Die GCC 2.95 Serie ist ein offizielles GNU-Release und Version 2.95.3 ist die fehlerfreieste dieser Serie. Wir haben niemals Compilier-Probleme beobachten können, die auf den GCC 2.95.3 zurückzuführen gewesen wären. Angefangen mit Red Hat Linux 7.0 begann Red Hat eine stark veränderte CVS-Version des GCC mitzuliefern und nannte sie 2.96. Red Hat hat diese Version in seine Distribution aufgenommen, weil GCC 3.0 zu diesem Zeitpunkt noch nicht fertiggestellt war und weil sie einen Compiler brauchten, der auf allen unterstützten Plattformen gut arbeitete, einschließlich IA64 und s390. Der Linux-Distributor Mandrake (jetzt Mandriva) folgte ebenfalls dem Beispiel Red Hat's und begann bald darauf, GCC 2.96 mit seiner Linux-Mandrake 8.0 Serie auszuliefern. Die Stellungnahmen: Das GCC-Team dementierte jegliche Verbindung zu GCC 2.96 und publizierte eine offizielle Stellungnahme auf GCC 2.96. Viele Entwickler weltweit trafen auf Probleme mit GCC 2.96 und verschiedene Projekte, darunter avifile, und fingen an, andere Compiler zu empfehlen. Weitere interessante Links sind der Linux kernel news flash about kernel 2.4.17 und das Voy Forum. MPlayer litt ebenfalls zeitweilig an Problemen, die alle durch den Wechsel zu einer anderen Version von GCC ausgelöst worden waren. Verschiedene Projekte begannen daraufhin damit, Workarounds für einige der Probleme mit 2.96 zu implementieren, aber wir lehnten es ab, Fehler anderer Leute zu beheben. Dazu kommt, dass einige Workarounds zu Performance-Einbußen führten. GCC 2.96 erlaubt keine | (pipe-Zeichen) in Assembler-Kommentaren, weil er gleichermaßen die Intel- wie auch die AT&T-Syntax unterstützt und das Zeichen | ein Symbol in der Intel-Variante darstellt. Das Problem liegt nun darin, dass der GCC den kompletten Assembler-Block stillschweigend ignoriert. Dieser Fehler wurde inzwischen angeblich behoben. GCC gibt eine Warnung aus anstatt den Block einfach zu überspringen. Die Gegenwart: Red Hat erklärt, dass GCC 2.96-85 und neuer keine Fehler mehr enthalten. Die Situation hat sich tatsächlich verbessert, jedoch sehen wir nach wie vor Problemberichte auf unseren Mailing-Listen, die mit Verwenden eines anderen Compilers verschwinden. Wie dem auch sei, es ist inzwischen nicht mehr von Bedeutung. Hoffentlich wird ein herangereifter GCC 3.x all dieses Problem ein für alle mal beheben. Wenn du wirklich mit 2.96 compilieren willst, füge configure die Option hinzu. Vergiss nicht, du bist auf dich allein gestellt, melde keine Bugs. Tust du dies trotzdem, wirst du nur aus der Mailing-Liste verbannt, da wir mehr als genug Flamewars wegen GCC 2.96 erlebt hatten. Lass dieses Thema bitte ruhen. Solltest du Probleme mit dem GCC 2.96 haben, bekommst du Pakete für die Version 2.96-85 auf Red Hats FTP-Server, oder benutze einfach die der Version 7.2 und neuer bereitliegenden Pakete für die Version 3.0.4. Du kannst auch Pakete für gcc-3.2.3-37 herunterzuladen (inoffiziell, aber sie funktionieren einwandfrei), und du kannst diese analog zu deinem GCC 2.96 installieren. MPlayer wird das erkennen und Version 3.2 statt 2.96 verwenden. Wenn du aus irgendeinem Grund die binären Pakete nicht anwenden willst oder kannst, lies hier eine kleine Anleitung, wie du GCC 3 aus den Quellen compilieren kannst: Gehe zur Seite mit den GCC-Mirrors und lade gcc-core-XXX.tar.gz herunter, wobei XXX die Versionsnummer bedeutet. Dieses Paket beinhaltet den kompletten C-Compiler und reicht für MPlayer aus. Willst du darüber hinaus Unterstützung für C++, Java oder einige der erweiterten GCC-Features, ist gcc-XXX.tar.gz womöglich besser für deine Bedürfnisse geeignet. Entpacke das Archiv mit tar -xvzf gcc-core-XXX.tar.gz Der GCC ist nicht innerhalb des Quelltextverzeichnisses selbst eingebaut wie andere Programme, sondern benötigt ein spezielles Build-Verzeichnis ausserhalb des Quelltextbaumes. Deshalb erstelle dieses Verzeichnis mit mkdir gcc-build Danach kannst du mit dem Konfigurieren des GCC im Build-Verzeichnis fortfahren, du brauchst aber das configure-Script aus dem Quelltextverzeichnis: cd gcc-build ../gcc-3.XXX/configure Compiliere GCC mit folgendem Befehl im Build-Verzeichnis: make bootstrap Jetzt kannst du GCC (als root) mit diesem Befehl installieren make install Vorcompilierte (binäre) Pakete Früher enthielt MPlayer Quelltext des OpenDivX-Projekts, welches es verbietet, vorcompilierte Pakete zu verteilen. Dieser Code wurde in Version 0.90-pre1 entfernt, und die verbliebene Datei divx_vbr.c, die noch auf den OpenDivX-Quellen aufbaut, wurde wie Version 0.90pre9 durch die Autoren unter die GPL gestellt. Du darfst jetzt also nach Herzenslust binäre Pakete bauen und verteilen. Ein weiteres Hindernis für Binärpakete waren Optimierungen der Compilierzeit für die CPU-Architektur. MPlayer unterstützt nun die CPU-Erkennung zur Laufzeit (übergib configure einfach ). Diese Option ist standardmäßig deaktiviert, weil es 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-kompatiblen CPU-Familie laufen. nVidia Uns misfällt die Tatsache, dass nVidia nur binäre Treiber (zur Verwendung mit XFree86) bereitstellt, die oft genug auch noch einige Fehler enthalten. Wir bekamen auf mplayer-users viele Berichte über Probleme, die diese Closed-Source-Treiber und deren dürftige Qualität, Instabilität und armseligen User- und Experten-Support betreffen. Viele dieser Probleme/Sachverhalte treten nach wie vor immer wieder auf. nVidia hat letztens Kontakt mit uns aufgenommen und behauptet, diese Fehler würden nicht existieren, die Instabilität würde von schlechten AGP-Chips verursacht, und sie hätten keine Fehlerberichte (wie etwa die lila Linien) erhalten. Wenn du also ein Problem mit deiner nVidia-Karte hast, solltest du du auf jeden Fall deinen nVidia-Treiber aktualisieren und/oder ein neues Motherboard kaufen oder nVidia um die Bereitstellung von Open-Source-Treibern bitten. Wie dem auch sei, wenn du binäre nVidia-Treiber verwendest und Treiberprobleme auftreten, sei dir bitte bewusst, dass du von unserer Seite aus sehr wenig Hilfe erhalten wirst, da wir in diesem Falle einfach wenig helfen können. Joe Barr Joe Barr wurde im Dezember 2001 durch das Verfassen eines für MPlayer mehr als üblen Berichts berüchtigt, genannt MPlayer: The project from hell. Er war der Meinung, MPlayer sei schwer zu installieren und kam zu dem Schluß, die Entwickler seinen unfreundlich und die Dokumentation unvollständig und beleidigend. Entscheide selbst, wie es darum steht. Er fuhr fort, Arpi negativ in seinen 10 Linux predictions for 2002 zu erwähnen. In einem darauf folgenden Bericht von xine, genannt A streaming media player for the rest of us, machte er mit dem Hochrühren der Kontroverse weiter. Ironischerweise zitiert er am Ende dieses Artikels seine Konversation mit Günter Bartsch, dem Autor von xine, der die ganze Situation perfekt zusammenfasste:
Seis drum, er sagte auch noch, er sei "überrascht" von meiner Kolumne zu MPlayer gewesen und meinte, sie sei unfair, während er mich daran erinnerte, es sei ein freies Software-Projekt. "Wenn du ihn nicht magst," sagte Bartsch, "steht es dir frei, ihn nicht zu nutzen."
Fast zwei Jahre später im Oktober 2003 schrieb er einen anderen Bericht, genannt Mplayer revisited (falsche Rechtschreibung wurde beibehalten). Darin kam er zu folgenden Schlussfolgerungen:
Ich würde gerne erzählen, es hätte bei der Anzahl der Features, in der Performance und in der Dokumentation Verbesserungen gegeben. Es ist nach wie vor nicht die leichteste Installation der Welt, speziell für Neulinge, aber es ist ein bisschen besser als es mal war.
und
Aber noch wichtiger, mir sind keinerlei neue Kommentare zum Missbrauch durch Nutzer aufgefallen. Ich denke, ich verdiene etwas von dem Ansehen dafür, auch wenn ich das selbst nicht so sage. Arpi und der Rest des Projektteams muss das auch so empfinden, da sie darauf bedacht waren, sich in einem speziellen, im Tarball enthaltenen Abschnitt der Dokumentation an mich zu erinnern. Wie ich anfangs schon sagte, die Dinge haben sich überhaupt nicht geändert.
Wir konnten unsere Gefühle für Joe Barr nicht besser zusammen fassen: "Es ist nach wie vor nicht der fairste oder am besten recherchierte Artikel der Welt, aber er ist besser als früher. "Hoffentlich werden wir das nächste Mal jedermanns Erwartungen entsprechen. Wie auch immer, die Reife ist nur unserem wachsenden Alter gutzuschreiben und womöglich der Tatsache, dass wir der Flamewars müde sind.