mirror of
https://github.com/mpv-player/mpv
synced 2024-12-13 18:36:09 +00:00
f50edb709c
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@12816 b3059339-0415-0410-9bf9-f77b7e298cf2
228 lines
9.7 KiB
XML
228 lines
9.7 KiB
XML
<?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> 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 started recommending other compilers. Examples are
|
||
<ulink url="http://www.mysql.com/downloads/mysql-3.23.html">MySQL</ulink>,
|
||
and
|
||
<ulink url="http://avifile.sourceforge.net/news-old1.htm">avifile</ulink>.
|
||
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/3.2.3-11/">gcc-3.2.3-11 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>
|