mirror of
https://github.com/mpv-player/mpv
synced 2024-12-11 17:37:23 +00:00
73158ed870
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@5118 b3059339-0415-0410-9bf9-f77b7e298cf2
192 lines
8.9 KiB
HTML
192 lines
8.9 KiB
HTML
<HTML>
|
|
|
|
<HEAD>
|
|
<STYLE>
|
|
.text
|
|
{font-family : Verdana, Arial, Helvetica, sans-serif;
|
|
font-size : 14px;}
|
|
</STYLE>
|
|
</HEAD>
|
|
|
|
<BODY BGCOLOR=white>
|
|
|
|
<FONT CLASS="text">
|
|
|
|
<P><B><I>In medias res</I></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>
|
|
|
|
<A NAME=gcc><P><B><I>GCC 2.96 series</I></B></P>
|
|
|
|
<P><B>Also read <A HREF="gcc-2.96-3.0.html">this</A> text !!!</B></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>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>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>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><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>
|
|
|
|
<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>
|
|
</UL>
|
|
</P>
|
|
|
|
<A NAME=binary><P><B><I>Binary distribution of MPlayer</I></B></P>
|
|
|
|
<P>Tons of users asked us about this. For example Debian users tend to say: Oh,
|
|
I can <CODE>apt-get install avifile</CODE>, why should I <B>compile MPlayer</B> ?
|
|
While this may sound reasonable, the problem lies a bit deeper than
|
|
those-fuckin-MPlayer-developers-hate-gcc-2.96-and-RedHat-and-Debian.</P>
|
|
|
|
<P>Reasons: <B>Law</B></P>
|
|
|
|
<P><B>MPlayer</B> describes the <U>sourcecode</U>. It contains several files with incompatible
|
|
licenses especially on the redistribution clauses. As source files, they are
|
|
allowed to coexist in a same project.</P>
|
|
|
|
<P>Therefore, <U>NEITHER BINARIES NOR BINARY PACKAGES OF <B>MPlayer</B> ARE ALLOWED TO EXIST SINCE
|
|
SUCH OBJECTS BREAK LICENSES</U>. PEOPLE WHO DISTRIBUTE SUCH BINARY PACKAGES ARE
|
|
DOING ILLEGAL ACTIVITIES.</P>
|
|
|
|
<P>So if you know somebody who maintains a binary package then forward her/him
|
|
this text and (ask him to) contact us. What (s)he is doing is illegal and IT IS
|
|
NO LONGER <B>MPlayer</B>, but <U>his/her</U> mplayer. If it breaks, it is
|
|
his/her fault. Don't come and cry on the <B>MPlayer</B> mailing lists, you will
|
|
most likely be blacklisted.</P>
|
|
|
|
<P>Reasons: <B>Technical</B></P>
|
|
|
|
<P>
|
|
<UL>
|
|
<LI><B>MPlayer's</B> speed (MMX, SSE, fastmemcpy, etc) optimizations are
|
|
determined during compilation. Thus a compiled binary contains very
|
|
processor-specific code. An <B>MPlayer</B> binary compiled for K6 will die
|
|
on Pentiums and vice versa. This has to be workarounded by runtime
|
|
detection, which is not an easy thing to do becase it causes massive speed
|
|
decrease. If you don't believe (it was explained in details 10000 times on
|
|
mplayer-users, search the archive), solve it and send us a patch. Someone
|
|
begun work on it, but disappeared since then.</LI>
|
|
<LI><B>MPlayer's</B> video/audio system is not plugin based. It is compiled
|
|
into the binary, thus making the binary depend on various libraries (the
|
|
GUI depends on GTK, DivX4 depends on libdivxdecore, SDL depends on libSDL,
|
|
every SDL release contains an unique bug that has to be workarounded during
|
|
compiletime, X11 output compiles differently for X3 and X4, etc). You may
|
|
say: yes, let's make 30 versions of downloadable binaries! We won't. We
|
|
will make these stuff pluggable in the future.</LI>
|
|
</UL>
|
|
|
|
<P>We will (at least we wish) solve 2 of these problems in the next major release:
|
|
the legal problems (we're on removing all non-GPL codes and getting others to
|
|
change license to GPL) and the runtime CPU detection. Anyway, dependency on
|
|
various libraries, versions and environment parameters will remain.</P>
|
|
|
|
|
|
<A NAME=nvidia><P><B><I>NVidia</I></B></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>
|
|
|
|
<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
|
|
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>
|
|
|
|
<P><I>"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
|
|
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>
|
|
|
|
</HTML>
|