applied Nilmoni Debian's (and Diego Burrick) patch

git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@6015 b3059339-0415-0410-9bf9-f77b7e298cf2
This commit is contained in:
gabucino 2002-05-08 18:00:26 +00:00
parent 1bff6e8bc3
commit 53dd3f5605
1 changed files with 147 additions and 105 deletions

View File

@ -12,130 +12,172 @@
<FONT CLASS="text">
<P><B><I>In medias res</I></B></P>
<P><B>In medias res</B></P>
<P>There are two major topic which always causes huge dispute and flame on the
<A HREF="http://www.MPlayerHQ.hu/cgi-bin/htsearch">mplayer-users</A>
mailing list. Number one is of course the topic of the</P>
<P>There are two major topics which always cause huge dispute and flame on the
<A HREF="http://mplayerhq.hu/pipermail/mplayer-users/">mplayer-users</A>
mailing list. Number one is the topic of the</P>
<A NAME=gcc><P><B><I>GCC 2.96 series</I></B></P>
<P><A NAME=gcc><B>GCC 2.96 series</B></A></P>
<P><B>Also read <A HREF="gcc-2.96-3.0.html">this</A> text !!!</B></P>
<P><B>The background:</B> The GCC <B>2.95</B> 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, <B>Red Hat</B> included a heavily
patched CVS version of GCC in their distribution and named it <B>2.96</B>. 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 <B>Mandrake</B>
also followed Red Hat's example and started shipping GCC 2.96 with their
Linux-Mandrake 8.0 series. </P>
<P>The <I>background</I> : there were/are the GCC <B>2.95</B> series. The
best of them was 2.95.3 . Please note the style of the version numbering.
This is how the GCC team numbers their compilers. The 2.95 series are good.
We never ever saw anything that was miscompiled because of the 2.95.3's faultiness.</P>
<P><B>The statements:</B> The GCC team disclaimed any link with GCC 2.96 and issued an
<A HREF="http://gcc.gnu.org/gcc-2.96.html">official response</A> to GCC 2.96.
Many developers around the world began having problems with GCC 2.96, and
started recommending other compilers. Examples are
<A HREF="http://www.apachelabs.org/apr-mbox/200106.mbox/%3c20010623194228.C25512@ebuilt.com%3e">Apache</A>,
<A HREF="http://www.mysql.com/downloads/mysql-3.23.html">MySQL</A>,
<A HREF="http://avifile.sourceforge.net/news-old1.htm">avifile</A> and
<A HREF="http://www.winehq.com/news/?view=92#RH 7.1 gcc fixes compiler bug">Wine</A>.
Other interesting links are
<A HREF="http://www.realtimelinux.org/archives/rtai/20017/0144.html">Real time Linux</A>,
<A HREF="http://www.atnf.csiro.au/people/rgooch/linux/docs/kernel-newsflash.html">
Linux kernel news flash about kernel 2.4.17</A> and
<A HREF="http://www.voy.com/3516/572.html">Voy Forum</A>.
<B>MPlayer</B> 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.</P>
<P>The <I>action</I> : <B>RedHat</B> started to include a GCC version of <B>2.96</B>
with their distributions. Note the version numbering. This should be the GCC
team's versioning. They patched the CVS version of GCC (something between 2.95 and 3.0)
They patched it very deep, and used this version in the distrib because 3.0
wasn't out at time, and they wanted IA64 support ASAP (business reasons).
Oh, and GCC 2.95 miscompiles bash on the s390 architecture...</P>
<P>You can read about the other side of the story
<A HREF="http://www.bero.org/gcc296.html">here</A>.
GCC 2.96 does not allow | (pipe) characters in assembler comments
because it supports Intel as well as AT&amp;T Syntax and the | character is a
symbol in the Intel variant. The problem is that it <B>silently</B> ignores the
whole assembler block. This is supposedly fixed now, GCC prints a warning instead
of skipping the block.</P>
<P>The <I>facts</I> : <B>MPlayer</B>'s compile process needs the
<CODE>--disable-gcc-checking</CODE> to proceed upon detecting a GCC version of
2.96 (apparently it needs this option on <B>egcs</B> too. It's because we don't
test <B>MPlayer</B> on egcs. Pardon us, but we rather develop <B>MPlayer</B>).
If you know <B>MPlayer</B>, you should know that it has great speed. It
achieves this by having overoptimized MMX/SSE/3DNow/etc codes, fastmemcpy, and
lots of other features. <B>MPlayer</B> contained MMX/3DNow instructions in a
syntax that all Linux compilers accept it... except RedHat's GCC (it's more
standard compliant). It simply <B><I>skips</I></B> them. It doesn't give
errors. It doesn't give warnings. <B>And</B>, there is Lame. With gcc 2.96, its quality check
(<CODE>make test</CODE> after compiling) <I>doesn't even run !!!</I>
But hey, it compiles bash on s390 and IA64.</P>
<P><B>The present:</B> 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 <CODE>--disable-gcc-checking</CODE>
flag to configure. Remember that you are on your own and <B>do not report any
bugs</B>. 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.</P>
<P>The <I>statements</I> : most developers around the world begun having
bad feelings about RedHat's GCC 2.96 , and told their RedHat users to
compile with other compiler than 2.96 . RedHat users' disappointment slowly
went into anger. What was all good
for, apart from giving headaches to developers, putting oil on anti-RedHat
flame, confusing users? The answer, I do not know.</P>
<P>If you have problems with GCC 2.96, here is how you can get GCC 3.0.4 to work
(submitted by <A HREF="mailto:willis_matthew@yahoo.com">Matt Willis</A>):</P>
<P><I>Present age, present time</I> : RedHat says that GCC 2.96-85 and above
is fixed, and works properly. Note the versioning. They should have started
with something like this. What about GCC 2.96.85 ? It doesn't matter now.
I don't search, but I still see bugs with 2.96 . It doesn't matter now,
hopefully now <B>RedHat will forget about 2.96</B> and turn towards <B>3.0</B>.
Towards a deep patched 3.0...
</P>
<P><I>What I don't understand</I> is why are we hated by RedHat users for
putting warning messages, and stay-away documents in <B>MPlayer</B> .
Why are we called "brain damaged", "total asshole", "childish" by
<B>RedHat users</B>, on our mailing list, and even on the <B>redhat-devel</B> .
They even considered forking <B>MPlayer</B> for themselves. RedHat users.
Why? It's RedHat that made the compiler, why do <U>you</U> have to hate us?
Are you <U>that</U> fellow RedHat worshippers? Please stop it. We don't hold
a grudge against users, doesn't matter how loud you advertise its contrary.
Please go flame Linus Torvalds, the DRI developers (oh, now I know why
there were laid off by VA!), the Wine, avifile. Even if we are arrogant,
are we not the same as the previously listed ones? Why do <B>we</B> have
to suffer from your unrightful wrath?</P>
<P><A HREF="mailto:willis_matthew@yahoo.com">Matt Willis</A> kindly submitted
a simple GCC-3.0.3 compiling howto, I'm copying it here:</P>
<P>
<UL>
<LI>Download gcc. Go to the <A
HREF="http://gcc.gnu.org/mirrors.html">http://gcc.gnu.org/mirrors.html</A>
page.
I downloaded the following, but you don't need everything:<BR>
<CODE>gcc-g++-3.0.3.tar.gz<BR>
gcc-objc-3.0.3.tar.gz<BR>
gcc-3.0.3.tar.gz<BR>
gcc-g77-3.0.3.tar.gz<BR>
gcc-testsuite-3.0.3.tar.gz<BR>
gcc-core-3.0.3.tar.gz<BR>
gcc-java-3.0.3.tar.gz</CODE>
<LI>Go to the
<A HREF="http://gcc.gnu.org/mirrors.html">GCC mirrors page</A>
page and download the following (you may not need everything):<BR>
<CODE>gcc-g++-3.0.4.tar.gz<BR>
gcc-objc-3.0.4.tar.gz<BR>
gcc-3.0.4.tar.gz<BR>
gcc-g77-3.0.4.tar.gz<BR>
gcc-testsuite-3.0.4.tar.gz<BR>
gcc-core-3.0.4.tar.gz<BR>
gcc-java-3.0.4.tar.gz</CODE>
</LI>
<LI>Unpack the files, make a build directory, and build<CODE><PRE>
tar xvzf gcc-*3.0.3.tar.gz
mkdir gcc-build; cd gcc-build
../gcc-3.0.3/configure --prefix=/opt --program-suffix=-3.0.3
make bootstrap; mkdir -p /opt; make install</PRE></CODE>
<LI>Set your path to include /opt/bin<BR>
<CODE>export PATH=/opt/bin:${PATH}</CODE>
<LI>Now you can build MPlayer.</LI>
<LI>Unpack the files, make a build directory, and build:<BR>
<CODE>tar -xvzf gcc-*3.0.4.tar.gz<BR>
mkdir gcc-build<BR>
cd gcc-build<BR>
../gcc-3.0.4/configure --prefix=/opt --program-suffix=-3.0.4<BR>
make bootstrap; mkdir -p /opt; make install</CODE></LI>
<LI>Set your path to include <CODE>/opt/bin</CODE><BR>
<CODE>export PATH=/opt/bin:${PATH}</CODE></LI>
</UL>
<P><A NAME=binary><B>Binary distribution of MPlayer</B></A></P>
<P>This was the second big problem but has been solved as of version
0.90-pre1. <B>MPlayer</B> previously contained source from the OpenDivX project,
which disallows binary redistribution. This code has been removed and you are now
welcome to create binary packages as you see fit.</P>
<P>Another impediment to binary redistribution was compiletime optimizations
for CPU architecture. <B>MPlayer</B> now supports runtime CPU detection.
Although this implies a small speed sacrifice, it is now possible to create
binaries that run on different members of the Intel CPU family. For optimum
performance you may wish to disable runtime CPU detection before compilation
(<CODE>configure --disable-runtime-cpudetection</CODE>).</P>
<P><A NAME=nvidia><B>nVidia</B></A></P>
<P>We dislike the fact that <A HREF="http://www.nvidia.com">nVidia</A>
only provides binary drivers (for use with XFree86), which are often buggy.
We have had many reports on
<A HREF="http://mplayerhq.hu/pipermail/mplayer-users/">mplayer-users</A>
about problems related to these closed-source drivers
and their poor quality, instability and poor user and expert support.
Here is an example from the
<A HREF="http://www.nvnews.net/forum/showthread.php?s=fda5725bc2151e29453b2da3bd5d2930&threadid=14306">
nVidia Linux Forum</A>.
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.</P>
<P><A NAME=kotsog><B>Joe Barr</B></A></P>
<P>Joe Barr became infamous by writing a less than favorable
<A HREF="http://www.linuxworld.com/site-stories/2001/1214.mplayer.html">
<B>MPlayer</B> review</A>. He found <B>MPlayer</B> hard to install, but then
again he is not very fond of
<A HREF="http://www.linuxworld.com/linuxworld/lw-2000-06/lw-06-exam.html">reading documentation</A>.
He also concluded that the developers were unfriendly and the documentation
incomplete and insulting. You be the judge.
He went on to mention <B>MPlayer</B> negatively in his
<A HREF="http://www.linuxworld.com/site-stories/2001/1227.predictions.html">10 Linux predictions for 2002</A>
In a followup
<A HREF="http://www.linuxworld.com/site-stories/2002/0125.xine.html">review of xine</A>
he continued stirring up controversy. Ironically at the end of that article he
quotes his exchange with Günter Bartsch, the original author of xine, that
perfectly summarizes the whole situation:</P>
<BLOCKQUOTE>
However, he also went on to say that he was "surprised" by my column about
Mplayer 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."
</BLOCKQUOTE>
</P>
<A NAME=nvidia><P><B><I>NVidia</I></B></P>
<P>He does not reply to our mails. His editor does not reply to our mails.
Here are some quotes from different people about Joe Barr, so you can form your
own opinion:</P>
<P>We don't like nvidia's binary drives, their quality, unstability,
non-existant user support, always appearing new bugs. And most users behave
the same. We've been contacted by NVidia lately, and they said these bugs
don't exist, unstability is caused by bad AGP chips, and they received
no reports of driver bugs (the purple line, for example). So: if you have
problem with your NVidia, update the nvidia driver and/or buy a new
motherboard.</P>
<P>Marc Rassbach has <A HREF="http://daily.daemonnews.org/view_story.php3?story_id=2102">something to say</A>
about the man
</P>
<A NAME=kotsog><P><B><I>Joe Barr</I></B></P>
<P>He doesn't reply to our mails. His editor doesn't reply to our mails.
The net is full with his false statements and accusitions (he apparently
doesn't like for example the BSD guys, because of their different viewpoints
[about what?]).</P>
<P>Now some quotes from different people about Joe Barr (just for you
understand why doesn't he matter at all):</P>
<P><I>"You may all remember the LinuxWorld 2000, when he claimed that Linus T said
<BLOCKQUOTE>
You may all remember the LinuxWorld 2000, when he claimed that Linus T said
that 'FreeBSD is just a handful of programmers'. Linus said NOTHING of the
sort. When Joe was called on this, his reaction was to call BSD supporters
assholes and jerks."</I></P>
assholes and jerks.
</BLOCKQUOTE>
<P><I>"He's interesting, but not good at avoiding, um... controversy. Joe Barr
<P>A <A HREF="http://www.mplayerhq.hu/pipermail/mplayer-users/2001-December/009118.html">quote</A>
from Robert Munro on the
<A HREF="http://mplayerhq.hu/pipermail/mplayer-users/">mplayer-users</A>
mailinglist:</P>
<BLOCKQUOTE>
<P>He's interesting, but not good at avoiding, um... controversy. Joe Barr
used to be one of the regulars on Will Zachmann's Canopus forum on Compuserve,
years ago. He was an OS/2 advocate then (I was an OS/2 fan too).
He used to go over-the-top, flaming people, and I suspect he had some hard
years ago. He was an OS/2 advocate then (I was an OS/2 fan too).<P>
<P>He used to go over-the-top, flaming people, and I suspect he had some hard
times, then. He's mellowed some, judging by his columns recently. Moderately
subtle humor was not his mode in those earlier days, not at all."</I></P>
subtle humor was not his mode in those earlier days, not at all.</P>
</BLOCKQUOTE>
</HTML>