Es gibt zwei Themen, die immer zu großen Streitereien und Beschimpfungen auf der mplayer-users Mailingliste führen. Das erste Thema dreht sich um den...
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.
Du kannst dir auch die andere Seite der Geschichte auf dieser Seite durchlesen. 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 compilieren
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 A HREF="ftp://people.redhat.com/jakub/gcc/3.2-10/">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 diesesn 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 compilieren kannst:
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.tar -xvzf gcc-core-XXX.tar.gzmkdir gcc-buildconfigure-Script liegt natürlich im
Quelltextverzeichnis:cd gcc-build
../gcc-XXX/configuremake bootstrapmake installFrüher enthielt MPlayer Teile des Quelltextes des OpenDivX-
Projektes, welches es verbietet, vorcompilierte 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
Compilierung 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.
Uns misfä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.
Joe Barr wurde dadurch berüchtigt, dass er einen mehr als schlechten Bericht über MPlayer veröffentlichte. Er war der Meinung, MPlayer sei schwierig zu installieren, aber andererseits mag er auch keine Dokumentation lesen. Er schloß auch damit, dass die MPlayer-Entwickler unfreundlich und die Dokumentation unvollständig seien. Entscheide selber, wie es damit steht. Er schreib weiter negativ über MPlayer in seinen 10 Vorhersagungen zu Linux für 2002. In einem folgenden Bericht über xine hat er weiter versucht, Rivalität zu schühren. Ironischerweise zitiert er am Ende dieses Artikels seine Konversation mit Günter Bartsch, dem Author von xine, der die ganze Situation perfekt zusammengefasst hat:
Er sagte auch noch, dass er von meiner Kolumne über MPlayer "überrascht" war und dachte, dass sie unfair sei. Er erinnerte mich daran, dass es sich dabei um freie Software handele. "Wenn du sie nicht magst", sagte Bartsch, "dann hast du die Freiheit, sie nicht zu benutzen."
Er antwortet auch nicht auf unsere Mails. Sein Editor antwortet ebenfalls nicht auf unsere Mails. Hier sind ein paar Zitate von verschiedenen Personen über Joa Barr, sodass du dir deine eigene Meinung bilden kannst:
Marc Rassbach hat etwas über den Kerl zu sagen:
Vielleicht erinnert ihr euch an die LinuxWorld 2000, bei der er behauptete, Linus T. habe gesagt: 'FreeBSD besteht nur aus einer Handvoll Programmierer.' Linus hat NICHTS dergleichen gesagt. Als Joe dazu zur Rede gestellt wurde, bestand seine Reaktion darin, die BSD-Unterstützer Arschlöcher und Idioten zu nennen.
Ein Zitat von Robert Munro von der mplayer-users Mailingliste:
Er ist interessant aber nicht besonders gut darin... hmm... Konflikte zu vermeiden. Joe Barr war vor Jahren ein regelmäßiger Besucher von Will Zachmanns Canopus-Forum bei Compuserve. Er war damals ein OS/2-Bfürworter (ich war damals ebenfalls ein OS/2-Fan).
Damals hat er ständig überreagiert, Leute beschimpft, und ich vermute, dass es für ihn damals ziemlich hart gewesen sein musste. Er hat sich seitdem ein wenig beruhigt, wenn man sich seine letzten Kolumnen durchliest. Subtiler Humor war aber auch damals schon nicht sein Fall - ganz und gar nicht.