arpi at thot.banki.hu
Wed Oct 24 00:34:41 CEST 2001
> On Tue, 23 Oct 2001 13:15:38 -0700,
> "Jilm Sanchez" <jilmy at onebox.com> wrote:
> > Just saying 'gcc 2.96 is buggy' does not cut it. Why would this user
> > get errors when compiling YOUR software, but no problems with ANYone
> > else's? Looks to me like it is YOUR bugs, not gcc's.
> > Blacklisting does nothing. Just makes people really upset and want to
> > smurf you. (If you understand that, then you'll realize what it means
> > about my Linux background.)
> I think it would be more productive if you used your Linux expertise to try
> and fix the code so that it would work with your favourite compiler (and share
> your work with everybody, which will no doubt make you a hero in many's eyes),
Thanks. This is the first mail in this thread what has sense, use.
Yes, you are right. If he say it's mplayer problem, he should trace down it
and fix it and send us the patch. I personally will *never* install gcc 2.96,
so I won't fix those probs. Same stay for other mplayer developers.
And for the people, who periodically asks what are the exact problems with
gcc 2.96, my answer: we don't know. we just see various bugreports mostly
gcc internal bugs, compiler syntax errors in source or bad code compiled. They
all are solved using different version of gcc. I understand that gcc 2.96
has different default optimization flags and they conflicts with our inline
asm code, but we can't fix them, and we really don't want to fix them as they
work with other compilers or gcc versions, and the fix may cause speed loss.
I think that the gcc 2.96 should be fixed to be option-compatible with other
releases, but redhat guys refused to do it. If someone interested - ask
Eugene K., avifile author, he has a long mailing with them, because they had
the same problems with avifile. Finally he changed avifile source to
*workaround* gcc 2.96 bugs...
We simply has no interest and time to do it.
Ah, and about the pipe-in-comment bug: it wasn't really our bug.
I've talked one of gcc maintainers, and he told me that gcc 2.96 and 3.x
supports intel asm syntax, and it caused the pipe bug. But it was a bug,
because gcc silently, without any warning, ignored the whole asm block.
*They* have fixed that, now it prints warning and doesn't skip the block.
(at least he told me, i didn't checked)
Other gcc 3.x problems comes from broken libstdc++ or glibc header
installation. They are not our fault. MPlayer compiles and work well with
gcc 3.x versions. Only 2.96 is broken, but it depends on many environment
elements, including gcc 2.96 release number, enabled mplayer features, etc.
If it works for you using gcc 2.96, it doesn't mean it will work for everyone.
I think it's time to touch DOCS/gcc-2.96-notes and paste this mail there.
> rather than bark at the developers for not doing what you want them to do for
> you, and stooping to smurf threats. This email makes you sound more like a
> script kiddie who can't code a single line of assembly than a Linux
A'rpi / Astral & ESP-team
mailto:arpi at thot.banki.hu
More information about the MPlayer-users