|
2867
|
1 <HTML>
|
|
|
2 <BODY BGCOLOR=white>
|
|
|
3
|
|
|
4 <FONT face="Verdana, Arial, Helvetica, sans-serif" size=2>
|
|
|
5
|
|
|
6 <P><B><I>In medias res</I></B></P>
|
|
|
7
|
|
|
8 <P>There are two major topic which always causes huge dispute and flame on the
|
|
|
9 <A HREF="http://www.MPlayerHQ.hu/cgi-bin/htsearch">mplayer-users</A>
|
|
|
10 mailing list. Number one is of course the topic of the</P>
|
|
|
11
|
|
|
12 <P><B><I>GCC 2.96 series</I></B></P>
|
|
|
13
|
|
|
14 <P>The <I>background</I> : there were/are the GCC <B>2.95</B> series. The
|
|
|
15 best of them was 2.95.3 . Please note the style of the version numbering.
|
|
|
16 This is how the GCC team numbers their compilers. The 2.95 series are good.
|
|
2910
|
17 We never ever saw anything that was miscompiled because of the 2.95's faultiness.</P>
|
|
2867
|
18
|
|
|
19 <P>The <I>action</I> : <B>RedHat</B> started to include a GCC version of <B>2.96</B>
|
|
|
20 with their distributions. Note the version numbering. This should be the GCC
|
|
2910
|
21 team's versioning. They patched the CVS version of GCC (something between 2.95 and 3.0)
|
|
2919
|
22 They patched it very deep, and used this version in the distrib because 3.0
|
|
|
23 wasn't out at time, and they wanted IA64 support ASAP (business reasons).
|
|
|
24 Oh, and GCC 2.95 miscompiles bash on the s390 architecture (there is
|
|
|
25 no RedHat distribution for s390..) .</P>
|
|
|
26
|
|
|
27 <P>The <I>facts</I> : <B>MPlayer</B>'s compile process needs the
|
|
|
28 <CODE>--disable-gcc-checking</CODE> to proceed upon detecting a GCC version of
|
|
|
29 2.96 (apparently it needs this option on <B>egcs</B> too. It's because we don't
|
|
|
30 test <B>MPlayer</B> on egcs. Pardon us, but we rather develop <B>MPlayer</B>).
|
|
|
31 If you know <B>MPlayer</B>, you should know that it has great speed. It
|
|
|
32 achieves this by having overoptimized MMX/SSE/3DNow/etc codes, fastmemcpy, and
|
|
|
33 lots of other features. <B>MPlayer</B> contained MMX/3DNow instructions in a
|
|
|
34 syntax that all Linux compilers accept it... except RedHat's GCC (it's more
|
|
|
35 standard compliant). It simply <B><I>skips</I></B> them. It doesn't give
|
|
2934
|
36 errors. It doesn't give warnings. <B>And</B>, there is Lame. With gcc 2.96, its quality check
|
|
|
37 (<CODE>make test</CODE> after compiling) <I>doesn't even run !!!</I>
|
|
|
38 But hey, it compiles bash on s390 and IA64.</P>
|
|
2867
|
39
|
|
|
40 <P>The <I>statements</I> : most developers around the world begun having
|
|
|
41 bad feelings about RedHat's GCC 2.96 , and told their RedHat users to
|
|
|
42 compile with other compiler than 2.96 . RedHat users' disappointment slowly
|
|
2910
|
43 went into anger. What was all good
|
|
2867
|
44 for, apart from giving headaches to developers, putting oil on anti-RedHat
|
|
|
45 flame, confusing users? The answer, I do not know.</P>
|
|
|
46
|
|
|
47 <P><I>Present age, present time</I> : RedHat says that GCC 2.96-85 and above
|
|
|
48 is fixed, and works properly. Note the versioning. They should have started
|
|
2910
|
49 with something like this. What about GCC 2.96.85 ? It doesn't matter now.
|
|
|
50 I don't search, but I still see bugs with 2.96 . It doesn't matter now,
|
|
|
51 hopefully now <B>RedHat will forget about 2.96</B> and turn towards <B>3.0</B>.
|
|
|
52 Towards a deep patched 3.0...
|
|
|
53 </P>
|
|
2867
|
54
|
|
|
55 <P><I>What I don't understand</I> is why are we hated by RedHat users for
|
|
|
56 putting warning messages, and stay-away documents in <B>MPlayer</B> .
|
|
|
57 Why are we called "brain damaged", "total asshole", "childish" by
|
|
|
58 <B>RedHat users</B>, on our mailing list, and even on the <B>redhat-devel</B> .
|
|
|
59 They even considered forking <B>MPlayer</B> for themselves. RedHat users.
|
|
|
60 Why? It's RedHat that made the compiler, why do <U>you</U> have to hate us?
|
|
|
61 Are you <U>that</U> fellow RedHat worshippers? Please stop it. We don't hold
|
|
|
62 a grudge against users, doesn't matter how loud you advertise its contrary.
|
|
|
63 Please go flame Linus Torvalds, the DRI developers (oh, now I know why
|
|
|
64 there were laid off by VA!), the Wine, avifile. Even if we are arrogant,
|
|
|
65 are we not the same as the previously listed ones? Why do <B>we</B> have
|
|
|
66 to suffer from your unrightful wrath?</P>
|
|
|
67
|
|
|
68 <P>I'm closing this topic. Think over it please. I (Gabucino) personally begun
|
|
|
69 with <A HREF="http://www.redhat.com">RedHat</A>, then used Mandrake (sorry I
|
|
|
70 don't know their URL), now I have <A
|
|
|
71 HREF="http://www.linuxfromscratch.com">LFS</A>. Never held a grudge against
|
|
|
72 RedHat or RedHat users, and I still don't. Hate is only comfortable. It
|
|
|
73 won't bring you anywhere.</P>
|
|
|
74
|
|
|
75 <P><B><I>Binary distribution of MPlayer</I></B></P>
|
|
|
76
|
|
2919
|
77 <P>Tons of users asked us about this. For example Debian users tend to say: Oh,
|
|
|
78 I can <CODE>apt-get install avifile</CODE>, why should I <B>compile MPlayer</B> ?
|
|
|
79 While this may sound reasonable, the problem lies a bit deeper than
|
|
2930
|
80 those-fuckin-MPlayer-developers-hate-gcc-2.96-and-RedHat-and-Debian.</P>
|
|
|
81
|
|
|
82 <P>Reasons: <B>Law</B></P>
|
|
|
83
|
|
|
84 <P><B>MPlayer</B> describes the <U>sourcecode</U>. It contains several files with incompatible
|
|
|
85 licenses especially on the redistribution clauses. As source files, they are
|
|
|
86 allowed to coexist in a same project.</P>
|
|
|
87
|
|
|
88 <P>Therefore, <U>NEITHER BINARIES NOR BINARY PACKAGES OF <B>MPlayer</B> ARE ALLOWED TO EXIST SINCE
|
|
|
89 SUCH OBJECTS BREAK LICENSES</U>. PEOPLE WHO DISTRIBUTE SUCH BINARY PACKAGES ARE
|
|
|
90 DOING ILLEGAL ACTIVITIES.</P>
|
|
|
91
|
|
|
92 <P>So if you know somebody who maintains a binary package then forward her/him
|
|
|
93 this text and (ask him to) contact us. What (s)he is doing is illegal and IT IS
|
|
|
94 NO LONGER <B>MPlayer</B>, but <U>his/her</U> mplayer. If it breaks, it is
|
|
|
95 his/her fault. Don't come and cry on the <B>MPlayer</B> mailing lists, you will
|
|
|
96 most likely be blacklisted.</P>
|
|
|
97
|
|
|
98 <P>For example that french guy called <B>Christian Marillat</B> who denied our
|
|
|
99 request, and is still distributing binary Debian packages of <B>MPlayer</B>,
|
|
|
100 despite the fact that there was at least one user who downloaded it and failed
|
|
|
101 (of course compiling from source helped him). And there is <B>Guillaume
|
|
|
102 Rousse</B>, who is doing the same, but making RPMs for Mandrake. Do not support
|
|
|
103 criminals!</P>
|
|
|
104
|
|
|
105 <P>Reasons: <B>Technical</B></P>
|
|
|
106
|
|
|
107 <P>
|
|
2919
|
108 <UL>
|
|
|
109 <LI><B>MPlayer's</B> speed (MMX, SSE, fastmemcpy, etc) optimizations are
|
|
|
110 determined during compilation. Thus a compiled binary contains very
|
|
|
111 processor-specific code. An <B>MPlayer</B> binary compiled for K6 will die
|
|
|
112 on Pentiums and vice versa. This has to be workarounded by runtime
|
|
|
113 detection, which is not an easy thing to do becase it causes massive speed
|
|
|
114 decrease. If you don't believe (it was explained in details 10000 times on
|
|
|
115 mplayer-users, search the archive), solve it and send us a patch. Someone
|
|
|
116 begun work on it, but disappeared since then.</LI>
|
|
|
117 <LI><B>MPlayer's</B> video/audio system is not plugin based. It is compiled
|
|
|
118 into the binary, thus making the binary depend on various libraries (the
|
|
|
119 GUI depends on GTK, DivX4 depends on libdivxdecore, SDL depends on libSDL,
|
|
|
120 every SDL release contains an unique bug that has to be workarounded during
|
|
|
121 compiletime, X11 output compiles differently for X3 and X4, etc). You may
|
|
|
122 say: yes, let's make 30 versions of downloadable binaries! We won't. We
|
|
|
123 will make these stuff pluggable in the future.</LI>
|
|
|
124 </UL>
|
|
2867
|
125
|
|
|
126 </HTML>
|
