Developer criesGCC 2.96The 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 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
MySQL,
and
avifile.
Other interesting links are
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.
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
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.
If you have problems with GCC 2.96, you can get 2.96-85 packages from the
Red Hat ftp server, or just
go for the 3.0.4 packages offered for version 7.2 and later. You can also
get gcc-3.2.3-11 packages
(unofficial, but working fine)
and you can install them along the gcc-2.96 you already have.
MPlayer will detect it and use 3.2 instead of 2.96.
If you do not want to or cannot use the binary packages, here is how you can
compile GCC 3 from source:
Go to the
GCC mirrors page
page and download gcc-core-XXX.tar.gz
where XXX is the version number. This includes the complete
C compiler and is sufficient for MPlayer. If you also want
C++, Java or some of the other advanced GCC features
gcc-XXX.tar.gz may better suit your needs.
Extract the archive with
tar -xvzf gcc-core-XXX.tar.gz
GCC is not built inside the source directory itself like most programs,
but needs a build directory outside the source directory. Thus you need
to create this directory via
mkdir gcc-build
Then you can proceed to configure gcc in the build directory, but you
need the configure from the source directory:
cd gcc-build
../gcc-3.XXX/configure
Compile GCC by issuing this command in the build directory:
make bootstrap
Now you can install GCC (as root) by typing
make installBinary distributionMPlayer previously contained source from the
OpenDivX project, which disallows binary redistribution.This code has been
removed in version 0.90-pre1 and the remaining file divx_vbr.c
that is derived from OpenDivX sources has been put under the GPL by its authors
as of version 0.90pre9. 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 (pass the
to configure).
It is disabled by default because it implies a small speed sacrifice, but it is
now possible to create binaries that run on different members of the Intel
compatible CPU family.
nVidia
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.
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.
Joe Barr
Joe Barr became infamous in december 2001 by writing a less than favorable
MPlayer review called
MPlayer: The project from hell.
He found MPlayer hard to install, and concluded
that the developers were unfriendly and the documentation
incomplete and insulting. You be the judge of that.
He went on to mention Arpi negatively in his
10 Linux predictions for 2002.
In a followup review of xine called
A streaming media player for the rest of us
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:
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."
Almost two years later in october 2003 he wrote another review called
Mplayer revisited.
In it he came to the following conclusions:
I would have to say that there have been improvements in the number of
features, in performance, and in documentation. It's still not the
easiest install in the world, especially for newbies, but it's a
little better than it used to be.
and
But more importantly, I didn't notice any recent comments about user
abuse. I think I deserve some of the credit for that, even if I do say
so myself. Arpi and the rest of the project team must feel that way
too, because they have taken care to remember me in a special section
of the documentation included in the tarball. Like I said at the
start, some things haven't changed at all.
We could not have summarized our feelings towards Joe Barr better:
"It's still not the fairest or best researched article in the world,
but it's better than it used to be." Hopefully the next time around
we will meet each other's expectations. However, the credit for maturity
goes to our increasing age only, and maybe to being weary of flame wars.