Mercurial > mplayer.hg
view DOCS/xml/en/users-vs-dev.xml @ 16911:a3d705105e01
Enabled OSD localization / moved msgs to help/help_mp-en.h
author | ptt |
---|---|
date | Sat, 05 Nov 2005 01:27:38 +0000 |
parents | 688fa06538ef |
children | 8accad9b453f |
line wrap: on
line source
<?xml version="1.0" encoding="iso-8859-1"?> <!-- $Revision$ --> <appendix id="users-vs-dev"> <title>Developer cries</title> <sect1 id="gcc-296"> <title>GCC 2.96</title> <formalpara> <title>The background:</title> <para> The GCC <emphasis role="bold">2.95</emphasis> series is an official GNU release and version 2.95.3 of GCC is the most bug-free in that series. We have never noticed compilation problems that we could trace to gcc-2.95.3. Starting with Red Hat Linux 7.0, <emphasis role="bold">Red Hat</emphasis> included a heavily patched CVS version of GCC in their distribution and named it <emphasis role="bold">2.96</emphasis>. Red Hat included this version in the distribution because GCC 3.0 was not finished at the time, and they needed a compiler that worked well on all of their supported platforms, including IA64 and s390. The Linux distributor <emphasis role="bold">Mandrake</emphasis> (now Mandriva) also followed Red Hat's example and started shipping GCC 2.96 with their Linux-Mandrake 8.0 series. </para> </formalpara> <formalpara> <title>The statements:</title> <para> The GCC team disclaimed any link with GCC 2.96 and issued an <ulink url="http://gcc.gnu.org/gcc-2.96.html">official response</ulink> to GCC 2.96. Many developers around the world began having problems with GCC 2.96, and several projects, <ulink url="http://avifile.sf.net/news-old1.htm">avifile</ulink> among them, started recommending other compilers. Other interesting links are <ulink url="http://www.atnf.csiro.au/people/rgooch/linux/docs/kernel-newsflash.html"> Linux kernel news flash about kernel 2.4.17</ulink> and <ulink url="http://www.voy.com/3516/572.html">Voy Forum</ulink>. <application>MPlayer</application> also suffered from intermittent problems that were all solved by switching to a different version of GCC. Several projects started implementing workarounds for some of the 2.96 issues, but we refused to fix other people's bugs, especially since some workarounds may imply a performance penalty. </para> </formalpara> <para> GCC 2.96 does not allow <literal>|</literal> (pipe) characters in assembler comments because it supports Intel as well as AT&T Syntax and the <literal>|</literal> character is a symbol in the Intel variant. The problem is that it <emphasis>silently</emphasis> ignores the whole assembler block. This is supposedly fixed now, GCC prints a warning instead of skipping the block. </para> <formalpara> <title>The present:</title> <para> Red Hat says that GCC 2.96-85 and above is fixed. The situation has indeed improved, yet we still see problem reports on our mailing lists that disappear with a different compiler. In any case it does not matter any longer. Hopefully a maturing GCC 3.x will solve the issue for good. If you want to compile with 2.96 give the <option>--disable-gcc-checking</option> flag to <filename>configure</filename>. Remember that you are on your own and <emphasis role="bold">do not report any bugs</emphasis>. If you do, you will only get banned from our mailing list because we have had more than enough flame wars over GCC 2.96. Please let the matter rest. </para> </formalpara> <para> If you have problems with GCC 2.96, you can get 2.96-85 packages from the Red Hat <ulink url="ftp://updates.redhat.com">ftp server</ulink>, or just go for the 3.0.4 packages offered for version 7.2 and later. You can also get <ulink url="ftp://people.redhat.com/jakub/gcc/errata/3.2.3-37/">gcc-3.2.3-37 packages</ulink> (unofficial, but working fine) and you can install them along the gcc-2.96 you already have. <application>MPlayer</application> will detect it and use 3.2 instead of 2.96. If you do not want to or cannot use the binary packages, here is how you can compile GCC 3 from source: </para> <procedure> <step><para> Go to the <ulink url="http://gcc.gnu.org/mirrors.html">GCC mirrors page</ulink> page and download <filename>gcc-core-<replaceable>XXX</replaceable>.tar.gz</filename> where <replaceable>XXX</replaceable> is the version number. This includes the complete C compiler and is sufficient for <application>MPlayer</application>. If you also want C++, Java or some of the other advanced GCC features <filename>gcc-<replaceable>XXX</replaceable>.tar.gz</filename> may better suit your needs. </para></step> <step><para> Extract the archive with <screen>tar -xvzf gcc-core-<replaceable>XXX</replaceable>.tar.gz</screen> </para></step> <step><para> GCC is not built inside the source directory itself like most programs, but needs a build directory outside the source directory. Thus you need to create this directory via <screen>mkdir gcc-build</screen> </para></step> <step><para> Then you can proceed to configure gcc in the build directory, but you need the configure from the source directory: <screen> cd gcc-build ../gcc-3.<replaceable>XXX</replaceable>/configure</screen> </para></step> <step><para> Compile GCC by issuing this command in the build directory: <screen>make bootstrap</screen> </para></step> <step><para> Now you can install GCC (as root) by typing <screen>make install</screen> </para></step> </procedure> </sect1> <sect1 id="mplayer-binary"> <title>Binary distribution</title> <para> <application>MPlayer</application> previously contained source from the OpenDivX project, which disallows binary redistribution.This code has been removed in version 0.90-pre1 and the remaining file <filename>divx_vbr.c</filename> that is derived from OpenDivX sources has been put under the GPL by its authors as of version 0.90pre9. You are now welcome to create binary packages as you see fit. </para> <para> Another impediment to binary redistribution was compiletime optimizations for CPU architecture. <application>MPlayer</application> now supports runtime CPU detection (pass the <option>--enable-runtime-cpudetection</option> to <command>configure</command>). It is disabled by default because it implies a small speed sacrifice, but it is now possible to create binaries that run on different members of the Intel compatible CPU family. </para> </sect1> <sect1 id="nvidia-opinions"> <title>nVidia</title> <para> We dislike the fact that <ulink url="http://www.nvidia.com">nVidia</ulink> only provides binary drivers (for use with XFree86), which are often buggy. We have had many reports on <ulink url="http://mplayerhq.hu/pipermail/mplayer-users/">mplayer-users</ulink> about problems related to these closed-source drivers and their poor quality, instability and poor user and expert support. Many of these problems/issues keep appearing repeatedly. We have been contacted by nVidia lately, and they said these bugs do not exist, instability is caused by bad AGP chips, and they received no reports of driver bugs (like the purple line). So if you have a problem with your nVidia card, you are advised to update the nVidia driver and/or buy a new motherboard or ask nVidia to supply open-source drivers. In any case, if you are using the nVidia binary drivers and facing driver related problems, please be aware that you will receive very little help from our side because we have little power to help in this matter. </para> </sect1> <sect1 id="joe-barr"> <title>Joe Barr</title> <para> Joe Barr became infamous in december 2001 by writing a less than favorable <application>MPlayer</application> review called <ulink url="http://www.linuxworld.com/story/32880.htm"><application>MPlayer</application>: The project from hell</ulink>. He found <application>MPlayer</application> hard to install, and concluded that the developers were unfriendly and the documentation incomplete and insulting. You be the judge of that. He went on to mention Arpi negatively in his <ulink url="http://www.linuxworld.com/story/32887.htm">10 Linux predictions for 2002</ulink>. In a followup review of xine called <ulink url="http://www.linuxworld.com/story/32716.htm">A streaming media player for the rest of us</ulink> he continued stirring up controversy. Ironically at the end of that article he quotes his exchange with Günter Bartsch, the original author of <application>xine</application>, that perfectly summarizes the whole situation: <blockquote><para> However, he also went on to say that he was "surprised" by my column about <application>Mplayer</application> and thought it was unfair, reminding me that it is a free software project. "If you don't like it," Bartsch said, "you're free not to use it." </para></blockquote> Almost two years later in october 2003 he wrote another review called <ulink url="http://www.newsforge.com/article.pl?sid=03/10/02/0343200">Mplayer revisited</ulink> (wrong spelling preserved). In it he came to the following conclusions: <blockquote><para> I would have to say that there have been improvements in the number of features, in performance, and in documentation. It's still not the easiest install in the world, especially for newbies, but it's a little better than it used to be. </para></blockquote> and <blockquote><para> But more importantly, I didn't notice any recent comments about user abuse. I think I deserve some of the credit for that, even if I do say so myself. Arpi and the rest of the project team must feel that way too, because they have taken care to remember me in a special section of the documentation included in the tarball. Like I said at the start, some things haven't changed at all. </para></blockquote> We could not have summarized our feelings towards Joe Barr better: "It's still not the fairest or best researched article in the world, but it's better than it used to be." Hopefully the next time around we will meet each other's expectations. However, the credit for maturity goes to our increasing age only, and maybe to being weary of flame wars. </para> </sect1> </appendix>