Mercurial > mplayer.hg
view DOCS/de/users_against_developers.html @ 17073:177c02c3785f
make -lavdopts debug work again, patch by Jason Tackaberry ( tack AH sault POIS org )
Original thread:
Subject: Re: [MPlayer-dev-eng] [PATCH] make -lavdopts debug work again
Date: Fri, 2 Dec 2005 01:38:02 +0100
| author | gpoirier |
|---|---|
| date | Fri, 02 Dec 2005 10:00:35 +0000 |
| parents | 883f38591d47 |
| children |
line wrap: on
line source
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <HTML> <HEAD> <TITLE>Developer Cries - MPlayer - The Movie Player for Linux</TITLE> <LINK REL="stylesheet" TYPE="text/css" HREF="../default.css"> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> </HEAD> <BODY> <H1><A NAME="appendix_e">Anhang E - Aufschrei der Entwickler</A></H1> <P>Es gibt zwei Themen, die immer zu großen Streitereien und Beschimpfungen auf der <A HREF="http://mplayerhq.hu/pipermail/mplayer-users/">mplayer-users</A> Mailingliste führen. Das erste Thema dreht sich um den...</P> <H2><A NAME="gcc">E.1 GCC 2.96</A></H2> <P><B>Zum Hintergrund:</B> Die Serie <B>2.95</B> 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 <B>Red Hat</B> damit, eine stark veränderte CVS-Version des GCC mitzuliefern. Diese Version nannten sie <B>2.96</B>. 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 <B>Mandrake</B> folgte bald darauf Red Hats Beispiel und lieferte ab Linux-Mandrake 8.0 ebenfalls den GCC 2.96 aus.</P> <P><B>Die Aussagen zu dem Thema:</B> Das GCC-Team hat jegliche Verbindung zu der Version 2.96 bestritten und dazu eine <A HREF="http://gcc.gnu.org/gcc- 2.96.html">offizielle Stellungnahme</A> abgegeben. Viele Entwickler auf der ganzen Welt trafen auf Probleme mit dem GCC 2.96 und empfahlen deswegen andere Compilerversionen. Beispiele dafür sind <A HREF="http://www.mysql.com/downloads/mysql-3.23.html">MySQL</A>, <A HREF="http://avifile.sourceforge.net/news-old1.htm">avifile</A> und <A HREF="http://www.winehq.com/news/?view=92#RH%207.1%20gcc%20fixes%20compiler%2 0bug">Wine</A>. Andere interessante Links sind der <A HREF="http://www.atnf.csiro.au/people/rgooch/linux/docs/kernel-newsflash.html"> Linux kernel news flash über den Kernel 2.4.17</A> und das <A HREF="http://www.voy.com/3516/572.html">Voy-Forum</A>. 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.</P> <P>Du kannst dir auch die andere Seite der Geschichte auf <A HREF="http://web.archive.org/web/20011024212120/http://www.bero.org/gcc296.ht ml"> dieser Seite</A> 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 <B>kommentarlos</B> 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.</P> <P><B>Die Gegenwart:</B> 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 <CODE>--disable-gcc-checking</CODE> bei <CODE>configure</CODE>. Denk aber daran, dass du dann auf dich allein gestellt bist. <B>Schick keine Fehlerberichte!</B> 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.</P> <P>Wenn du Probleme mit dem GCC 2.96 hast, so kannst du Pakete für die Version 2.96-85 auf <A HREF="ftp://updates.redhat.com/">Red Hats FTP- Server</A> 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</A> 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:</P> <OL> <LI>Lade dir <CODE>gcc-core-XXX.tar.gz</CODE> von einem der <A HREF="http://gcc.gnu.org/mirrors.html">GCC-Mirrorseiten</A> herunter, wobei <CODE>XXX</CODE> 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 <CODE>gcc- XXX.tar.gz</CODE> besser für dich geeignet.</LI> <LI>Entpacke das Archiv:<BR> <CODE>tar -xvzf gcc-core-XXX.tar.gz</CODE></LI> <LI>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<BR> <CODE>mkdir gcc-build</CODE></LI> <LI>Jetzt kannst du den GCC im Buildverzeichnis konfigurieren lassen - aber das <CODE>configure</CODE>-Script liegt natürlich im Quelltextverzeichnis:<BR> <CODE>cd gcc-build<BR> ../gcc-XXX/configure</CODE></LI> <LI>Compiliere GCC mit dem folgenden Kommando im Buildverzeichnis:<BR> <CODE>make bootstrap</CODE></LI> <LI>Jetzt kannst du (wenn du root bist) den GCC mit diesem Kommando installieren:<BR> <CODE>make install</CODE></LI> </OL> <H2><A NAME="binary">E.2 Vorcompilierte (binäre) Pakete</A></H2> <P>Frü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 <CODE>divx_vbr.c</CODE>, 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.</P> <P>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 <CODE>configure</CODE> mit der Option <CODE>--enable-runtime- cpudetection</CODE> 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.</P> <H2><A NAME="nvidia">E.3 nVidia</A></H2> <P>Uns misfällt die Tatsache, dass <A HREF="http://www.nvidia.com">nVidia</A> nur binäre Treiber für XFree86 zur Verfügung stellt, die oft genug auch noch einige Fehler enthalten. Auf <A HREF="http://mplayerhq.hu/pipermail/mplayer- users/">mplayer-users</A> 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 <A HREF="http://www.nvnews.net/vbulletin/forumdisplay.php?s=6d83dc289805c37caef4 9b77857a0b7e&daysprune=&forumid=27"> nVidia-Linux-Forum</A> 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.</P> <H2><A NAME="barr">E.4 Joe Barr</A></H2> <P>Joe Barr wurde dadurch berüchtigt, dass er einen mehr als schlechten <A HREF="http://www.linuxworld.com/site-stories/2001/1214.mplayer.html"> Bericht über MPlayer</A> veröffentlichte. Er war der Meinung, MPlayer sei schwierig zu installieren, aber andererseits mag er auch <A HREF="http://www.linuxworld.com/linuxworld/lw-2000-06/lw-06-exam.html"> keine Dokumentation lesen</A>. 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 <A HREF="http://www.linuxworld.com/site-stories/2001/1227.predictions.html">10 Vorhersagungen zu Linux für 2002</A>. In einem folgenden <A HREF="http://www.linuxworld.com/site-stories/2002/0125.xine.html">Bericht über xine</A> 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:</P> <BLOCKQUOTE> 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." </BLOCKQUOTE> <P>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:</P> <P>Marc Rassbach hat etwas <A HREF="http://daily.daemonnews.org/view_story.php3?story_id=2102">über den Kerl zu sagen</A>:</P> <BLOCKQUOTE> 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. </BLOCKQUOTE> <P>Ein <A HREF="http://www.mplayerhq.hu/pipermail/mplayer-users/2001- December/009118.html">Zitat</A> von Robert Munro von der <A HREF="http://mplayerhq.hu/pipermail/mplayer-users/">mplayer-users</A> Mailingliste:</P> <BLOCKQUOTE> <P>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).</P> <P>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.</P> </BLOCKQUOTE> </BODY> </HTML>