# HG changeset patch
# User gabucino
# Date 1020880826 0
# Node ID 4f0b13262397aef0e94282f7ad519d0da3e680fb
# Parent 7f6e02a16ac49ca76a59c367a6cae6064f20a584
applied Nilmoni Debian's (and Diego Burrick) patch
diff -r 7f6e02a16ac4 -r 4f0b13262397 DOCS/users_against_developers.html
--- a/DOCS/users_against_developers.html Wed May 08 16:41:44 2002 +0000
+++ b/DOCS/users_against_developers.html Wed May 08 18:00:26 2002 +0000
@@ -12,130 +12,172 @@
- In medias res In medias res There are two major topics which always cause huge dispute and flame on the
+mplayer-users
+mailing list. Number one is the topic of the There are two major topic which always causes huge dispute and flame on the
-mplayer-users
-mailing list. Number one is of course the topic of the GCC 2.96 series Also read this text !!! The background: The GCC 2.95 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, Red Hat included a heavily
+patched CVS version of GCC in their distribution and named it 2.96. 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 Mandrake
+also followed Red Hat's example and started shipping GCC 2.96 with their
+Linux-Mandrake 8.0 series. The background : there were/are the GCC 2.95 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. The statements: The GCC team disclaimed any link with GCC 2.96 and issued an
+official response to GCC 2.96.
+Many developers around the world began having problems with GCC 2.96, and
+started recommending other compilers. Examples are
+Apache,
+MySQL,
+avifile and
+Wine.
+Other interesting links are
+Real time Linux,
+
+Linux kernel news flash about kernel 2.4.17 and
+Voy Forum.
+MPlayer 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. The action : RedHat started to include a GCC version of 2.96
-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... You can read about the other side of the story
+here.
+GCC 2.96 does not allow | (pipe) characters in assembler comments
+because it supports Intel as well as AT&T Syntax and the | character is a
+symbol in the Intel variant. The problem is that it silently ignores the
+whole assembler block. This is supposedly fixed now, GCC prints a warning instead
+of skipping the block. The present: 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 If you have problems with GCC 2.96, here is how you can get GCC 3.0.4 to work
+(submitted by Matt Willis): The facts : MPlayer's compile process needs the
- Binary distribution of MPlayer This was the second big problem but has been solved as of version
+0.90-pre1. MPlayer 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. Another impediment to binary redistribution was compiletime optimizations
+for CPU architecture. MPlayer 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
+( The statements : 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. We dislike the fact that nVidia
+ only provides binary drivers (for use with XFree86), which are often buggy.
+We have had many reports on
+mplayer-users
+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
+
+nVidia Linux Forum.
+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. Present age, present time : 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 RedHat will forget about 2.96 and turn towards 3.0.
-Towards a deep patched 3.0...
+ Joe Barr became infamous by writing a less than favorable
+
+MPlayer review. He found MPlayer hard to install, but then
+again he is not very fond of
+reading documentation.
+He also concluded that the developers were unfriendly and the documentation
+incomplete and insulting. You be the judge.
+He went on to mention MPlayer negatively in his
+10 Linux predictions for 2002
+In a followup
+review of xine
+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:--disable-gcc-checking
+flag to configure. Remember that you are on your own and do not report any
+bugs. 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.--disable-gcc-checking
to proceed upon detecting a GCC version of
-2.96 (apparently it needs this option on egcs too. It's because we don't
-test MPlayer on egcs. Pardon us, but we rather develop MPlayer).
-If you know MPlayer, 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. MPlayer contained MMX/3DNow instructions in a
-syntax that all Linux compilers accept it... except RedHat's GCC (it's more
-standard compliant). It simply skips them. It doesn't give
-errors. It doesn't give warnings. And, there is Lame. With gcc 2.96, its quality check
-(make test
after compiling) doesn't even run !!!
-But hey, it compiles bash on s390 and IA64.
+
+
+
+ gcc-g++-3.0.4.tar.gz
+
+ gcc-objc-3.0.4.tar.gz
+ gcc-3.0.4.tar.gz
+ gcc-g77-3.0.4.tar.gz
+ gcc-testsuite-3.0.4.tar.gz
+ gcc-core-3.0.4.tar.gz
+ gcc-java-3.0.4.tar.gz
+ tar -xvzf gcc-*3.0.4.tar.gz
+ mkdir gcc-build
+ cd gcc-build
+ ../gcc-3.0.4/configure --prefix=/opt --program-suffix=-3.0.4
+ make bootstrap; mkdir -p /opt; make install/opt/bin
+ export PATH=/opt/bin:${PATH}
configure --disable-runtime-cpudetection
).
+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."
+
What I don't understand is why are we hated by RedHat users for -putting warning messages, and stay-away documents in MPlayer . -Why are we called "brain damaged", "total asshole", "childish" by -RedHat users, on our mailing list, and even on the redhat-devel . -They even considered forking MPlayer for themselves. RedHat users. -Why? It's RedHat that made the compiler, why do you have to hate us? -Are you that 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 we have -to suffer from your unrightful wrath?
- -Matt Willis kindly submitted - a simple GCC-3.0.3 compiling howto, I'm copying it here:
+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:
--
gcc-g++-3.0.3.tar.gz
- gcc-objc-3.0.3.tar.gz
- gcc-3.0.3.tar.gz
- gcc-g77-3.0.3.tar.gz
- gcc-testsuite-3.0.3.tar.gz
- gcc-core-3.0.3.tar.gz
- gcc-java-3.0.3.tar.gz
-
- 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
-
- export PATH=/opt/bin:${PATH}
-
- Marc Rassbach has something to say +about the man
-NVidia
- -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.
- -Joe Barr
- -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?]).
- -Now some quotes from different people about Joe Barr (just for you -understand why doesn't he matter at all):
- -"You may all remember the LinuxWorld 2000, when he claimed that Linus T said
+
+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."
"He's interesting, but not good at avoiding, um... controversy. Joe Barr +
A quote +from Robert Munro on the +mplayer-users +mailinglist:
+ ++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).
+ +
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."
+subtle humor was not his mode in those earlier days, not at all. +