view DOCS/German/gcc-2.96-3.0.html @ 4218:3931c41f740a

Added new syncengine thanks to a new previously undocumented feature of the em8300, this might fix playback on both slow and fast machines (more testing needed). This also requires users to get the em8300 driver from cvs until the next version is released (will probably happen this weekend) Added lots of comments, should be pretty easy to understand most of the internals now Added lots of brackets to if's for's while's etc, this is not a cosmetical thing but rather due to the fact I got some very odd bugs with else's since I didn't properly use brackets (and it's the K&R standard to have brackets everywhere) Fixed some bugs that would occur when disabling libmp1e Switched to default to the new naming scheme of device nodes, the driver will slowly switch over to this state, if it can't find devices under the new name it will try the old naming scheme I stopped opening devices in non-blocking mode, it would break the new syncengine which tries to burst data to the device (alot of times meaning it will fill the fifo pretty fast which would previously result in jerkyness on fast machines) The device now sets the initial state of the pts and speed (probably not needed, but assumption is the mother of all fuckups =) Keep the control interface open during the entire duration of the libvo device, we might need this to flush video buffers on seeking (currently not implemented, therefore seeking is broken) This is beta stuff to the driver, I will get some users to test it for me and do my best to fix seeking as soon as possible...
author mswitch
date Thu, 17 Jan 2002 10:33:47 +0000
parents 380db7806110
children 1bd05178a74d
line wrap: on
line source

<HTML>
<BODY BGCOLOR=WHITE>
<FONT face="Verdana, Arial, Helvetica, sans-serif" size=2>

<P>
<B>Frage:</B> Was ist GCC 2.96 ? Ich kann es auf der GNU Seite nicht finden.
</P>

<P>
<B>Antwort:</B> Lese die <A HREF="http://gcc.gnu.org/gcc-2.96.html">offzielle Antwort vom GNU GCC Team.</A>
</P>

<P>
<B>Frage:</B> Was ist das Problem mit GCC 2.96 ? Und mit 3.x ?
</P>

<P>
<B>Antwort:</B>
</P>

<P>
Für die Leute dir regelmäßig nach dem genauen Problem bei gcc 2.96 fragen, meine
Antwort: <I>wir wissen es nicht genau.</I> 
Es gibt einige Probleme und neue Probleme / Bugs kommen regelmäßig. Es ist
<I>nicht nur eine Bug/Problem</I>. We bekommen verschiedene Fehlerbericht, die
meisten sind gcc interne Bugs, Compiler Syntax-Fehler in der Source oder es wurde
eine schlechte Code kompiliert. Aber sie sind alle gelöst, wenn man einen andere
Version von gcc verwendet. Ich verstehe das gcc 2.96 verschiedene standardgemäße
Optimierungen eingestellt hat und dass diese mit unserem Inline ASM Code in Konflikt
treten, aber wir können diese nicht beheben und wollen es nicht wirklich beheben
denn es funktioniert mit anderen Compilern oder gcc Versionen und das Beheben
würde möglichweise einen Geschwindigkeitsverlust bedeuten.
</P>

<P>
Ich denke das gcc 2.96 gefixt werden sollte, das es Options-Kompatibel mit anderen
Releases ist, aber die Leute von RedHat lehnen das ab. Wenn jemeand interessiert ist -
frag Eugene K., der Avifile Autor, er besitzt eine lange Mails von ihnen, denn er hatte
dir selben Probleme mit Avifile. Schließlich hat er den Avifile-Quellcode geändert um
die gcc 2.96 bugs <I>zu umgehen</I>...
Wir haben dazu aber kein Interesse oder auch nur Zeit.
</P>

<P>
Achja und zum Pipe-In-Kommentar-Bug: Es war nicht unser Bug. Ich habe mit
einen der gcc Helfer gesprochen und sie haben mit gesagt, dass gcc 2.96 und 3.x
Intel ASM Syntax unterstützen und dies der Auslöser für den Pipe Bug war. Aber es war
ein Bug, denn gcc hat den ganzen ASM-Block stillschweigend ohne irgendeine Warnung
ignoriert. <I>Die Entwickler</I> hab das gelöst, nun gibt es Warnungen aus und
umgeht den Block nicht mehr. (zumindet hat er es mit gesagt, ich habe es nicht geprüft)
</P>

<P>
Andere gcc 3.x Probleme kommen von defekten libstdc++ oder glibc Header (std_*.h)
Installationen. Dies sind nicht unsere Fehler. MPlayer kann kompiliert werden und
funktioniert gut mit gcc 3.x Versionen. <B>Nur 2.96 ist defekt</B>, aber ist es abhängig
von einigen Umgebungselementen, wie gcc 2.96 Release Number, eingeschaltete MPlayer-Features, usw.
<I>Wenn es bei dir mit gcc 2.96 funktioniert, heisst das nicht, dass es überall funktioniert.</I>
</P>

<P>
<B>Frage:</B> Nein! Ihr liegt falsch! Es funktioniert alles mit gcc 2.96, <I>außer</I> MPlayer ...
</P>

<P>
<B>Answer:</B>
</P>

<P>
Nein. Du liegst falsch!
Einige Projekte (hauptsächlich Projekte, die Quelltext mit stark optimiertem
inline ASM Code) haben Probleme mit gcc 2.96. Zum Beispiel: avifile, MESA / DRI, Wine, ffmpeg, lame.
Aber andere Projekte habe habe bereits einen Workaround für die gcc Bugs eingebaut (Änderung
des Quellcodec er Compiler Bugs auslöst), deshalb funktioniert es nun.
</P>

<P>
<B>Frage:</B> Nein! Ihr liegt falsch! Es funktioniert alles mit gcc 2.96, <I>auch</I> MPlayer ...
</P>

<P>
<B>Antwort:</B>
</P>

Gut. Seih froh. Aber du musst wiessen, das es von manchen Umgebungselementen, wie
gcc 2.96 Release Number, eingeschaltete MPlayer-Features, usw. abhängen kann.
<I>Wenn es bei dir mit gcc 2.96 funktioniert, heisst das nicht, dass es überall funktioniert!</I>
Das bedeutet nur das du glücklich bist, bust du ein Problem erkennst. Aber vergiss die
<B>erste Regel für gcc 2.96 User nicht: BERICHTE UNS NIE PROBLEME ODER BUGS WENN DU GCC 2.96 VERWENDEST.</B>

<P>
<B>Frage:</B> Ok, verstanden. Aber ich will ihm eine Chance geben... wie kann ich mit gcc 2.96 kompilieren?
</P>

<P>
<B>Antwort:</B> Wirklich? Bist du sicher? Ok, du weisst es... hier ist es: ./configure --disable-gcc-checking
</P>

<P>
<B>Frage:</B> Nein! Ich kann euch nicht zustimmen, denn ...
</P>

<P>
<B>Antwort:</B> Das macht uns nichts aus. Spar dir deine Aussagen. Wir sind nicht interessiert an Geschichten über gcc 2.96.
</P>


</FONT>
</BODY>
</HTML>