diff options
author | gabucino <gabucino@b3059339-0415-0410-9bf9-f77b7e298cf2> | 2001-11-15 20:05:52 +0000 |
---|---|---|
committer | gabucino <gabucino@b3059339-0415-0410-9bf9-f77b7e298cf2> | 2001-11-15 20:05:52 +0000 |
commit | 8a21cc4e9c7596f0162332dc93045a7a7228dfc9 (patch) | |
tree | 9de9f4fd07449a2ee1ac860b6d1d5534a72f3b4a /DOCS | |
parent | de1287e1dde859a321ee281e56e4831ef0358e3b (diff) | |
download | mpv-8a21cc4e9c7596f0162332dc93045a7a7228dfc9.tar.bz2 mpv-8a21cc4e9c7596f0162332dc93045a7a7228dfc9.tar.xz |
more flame
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@2920 b3059339-0415-0410-9bf9-f77b7e298cf2
Diffstat (limited to 'DOCS')
-rw-r--r-- | DOCS/users_against_developers.html | 60 |
1 files changed, 49 insertions, 11 deletions
diff --git a/DOCS/users_against_developers.html b/DOCS/users_against_developers.html index 330f98e935..a7826c9bc1 100644 --- a/DOCS/users_against_developers.html +++ b/DOCS/users_against_developers.html @@ -11,14 +11,6 @@ mailing list. Number one is of course the topic of the</P> <P><B><I>GCC 2.96 series</I></B></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. - <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. @@ -27,8 +19,22 @@ We never ever saw anything that was miscompiled because of the 2.95's faultiness <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.</P> +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 (there is +no RedHat distribution for s390..) .</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. 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 @@ -67,6 +73,38 @@ won't bring you anywhere.</P> <P><B><I>Binary distribution of MPlayer</I></B></P> -<P>I'm too moody now for this.</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. +<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> + <LI><B>MPlayer</B> includes GPL codes, and some non-GPL ones + (like OpenDivX alpha 48). Arpi's demuxers and other code has a special + license which is like GPL with one exception: it doesn't allow binary + distribution. Thus, anyone who distributes a binary which contains Arpi's + code (which is the core of <B>MPlayer</B>) is doing a + <B><I>FORBIDDEN THING</I></B> ! For example that french guy called + <B>Christian Marillat</B> who denied our request, and is still distributing + binary Debian packages of <B>MPlayer</B>, despite the fact that there was + at least one user who downloaded it and failed (of course compiling from + source helped him). We're trying to be GPL, but there are still + problems to resolve. Don't come and flame, instead help (or better, + stay quiet). Thanks. +</UL> </HTML> |