1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
|
<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>
|
