gcc bug in mplayer?

Pagina: 1
Acties:

  • a casema user
  • Registratie: Januari 2000
  • Laatst online: 14-08 13:49
Ik krijg tegenwoordig altijd bij het comileren van CVS versie van MPlayer deze foutmelding.
../mplayer.h:11:6: warning: no newline at end of file
make -C mplayer
make[2]: Entering directory `/usr/local/cvs/mplayer/main/Gui/mplayer'
gcc -c -O4 -march=i686 -mcpu=i686 -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fomit-frame-pointer -fexpensive-optimizations -fschedule-insns2 -Wall -malign-double -I. -I../event -I../wm -I../skin -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -I/usr/share/doc/NVIDIA_GLX-1.0/include/ -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -I/usr/X11R6/include -DDEBUG -o mplayer.o mplayer.c
In file included from ../interface.h:7,
from mplayer.c:10:
../../mplayer.h:11:6: warning: no newline at end of file
In file included from mplayer.c:34:
mw.h: In function `mplMainDraw':
mw.h:197: Internal compiler error in print_rtl_and_abort, at flow.c:6458
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
make[2]: *** [mplayer.o] Error 1
make[2]: Leaving directory `/usr/local/cvs/mplayer/main/Gui/mplayer'
make[1]: *** [libgui.a] Error 2
make[1]: Leaving directory `/usr/local/cvs/mplayer/main/Gui'
make: *** [Gui/libgui.a] Fout 2
mijn gcc versie is:
# gcc -v
Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.0.3/specs
Configured with: ./configure
Thread model: single
gcc version 3.0.3
wat nu ? nieuwere / oudere versie van gcc opzoeken of wachten totdat MPlayer met een nieuwe CVS versie komt die er wel mee kan werken?

Taaaa taa taa taaaa taa taa ta taaataaaaa.


  • _JGC_
  • Registratie: Juli 2000
  • Laatst online: 14:39
GCC 3.0.3 is nogal buggy. Probeer 2.95.4 eens.

Verwijderd

Als mplayer zelfs met GCC 3.1 nog niet wil compilen, dan zou ik toch echt eens de sources van mplayer gaan verdenken.

De argumenten van de ontwikkelaars hieromtrent:

"Compilet niet met GCC 2.96, want dat is een niet standaard en incompatible compiler."

Okay, fair enough.

"Compilet niet met GCC 3.0.x, want daar zitten ook nog foutjes in."

Hmmm... :?

En over GCC 3.1 is er nagenoeg niets dan lof qua compatibiliteit en performance, en het is een officiele release, en dat werkt dan dus ook niet? What gives? :?

  • a casema user
  • Registratie: Januari 2000
  • Laatst online: 14-08 13:49
Ik ben al bezig met GCC 3.1.0 downloaden (met 5 Kb/sec, gaat lekker casema :) )
Als dat ook niet werkt zal ik het hier wel ff melden, maar dat duurt wel een paar uurtjes. (downloaden & compileren gcc)

Taaaa taa taa taaaa taa taa ta taaataaaaa.


Verwijderd

Op zondag 02 juni 2002 14:03 schreef motown het volgende:
De argumenten van de ontwikkelaars hieromtrent:

"Compilet niet met GCC 2.96, want dat is een niet standaard en incompatible compiler."

Okay, fair enough.
"fair enough"? Dachtutniet! :X.

  • foser
  • Registratie: Maart 2000
  • Laatst online: 26-06 15:03
Die gozers weten wel waar ze mee bezig zijn, dus die hebben 't volste recht om te zeggen wat te gebruiken en wat niet. Anyway, waarom wordt die zut hier gepost, daar zijn bugreports voor. Het is een CVS versie.. wat verwacht je ?

  • _JGC_
  • Registratie: Juli 2000
  • Laatst online: 14:39
XFree86 4.1.0 compileert ook niet met GCC 3.x, dus dat het waardeloos geprogrammeerd is, is gewoon onzin.

Als ik een programma helemaal optimaliseer voor M$ Visual C++, en ik wil het later compileren met GCC, zal dat ook niet lekker lukken, omdat de object code van GCC heel anders is dan die van MS Visual C++. Zo zit het ook met 2.95.4 en 3.x, er is veel veranderd tussen de verschillende versies.

  • a casema user
  • Registratie: Januari 2000
  • Laatst online: 14-08 13:49
na 3,5uur downloaden en compileren is gcc nu op 3.1
MPlayer (CVS) werkt daar dus wel op.

(lijkt me handig om dit te vermelden voor mensen die misschien tegen hetzelfde probleem aanlopen).

Taaaa taa taa taaaa taa taa ta taaataaaaa.


  • Valium
  • Registratie: Oktober 1999
  • Laatst online: 09-08 08:59

Valium

- rustig maar -

Op zondag 02 juni 2002 14:28 schreef beelzebubu het volgende:

[..]

"fair enough"? Dachtutniet! :X.
Dacht het wel. Het is geen officiele versie. Hij bestaat niet eens volgens de ontwikkelaars zelf. Het is uitgebracht door anderen (RedHat anyone?). Een programma als Mplayer probeert het onderste uit de kan te halen wat betreft prestaties en je kunt NMM niet verwachten van die mensen dat ze workarounds gaan verzinnen voor brakke versies van compilers.

Verder is het bekend dat GCC 3.0.x fouten bevat. Het compileerde de kernel ook nog niet. Die problemen zouden er in 3.1 uit gehaald moeten zijn. En jawel hoor. 3.1 compileert alles zonder problemen. Ik heb zelf ook al XFree86 met 3.1 gecompileerd (meerdere keren zelfs) en het werkt probleemloos.

Dus geen geklaag over de mensen van Mplayer. Ze hebben gelijk. 2.96 is bedroevend brak en 3.0 is ook nog vrij brak. 3.1 is goed.

  • a casema user
  • Registratie: Januari 2000
  • Laatst online: 14-08 13:49
Op zondag 02 juni 2002 21:21 schreef Valium het volgende:

[..]


Verder is het bekend dat GCC 3.0.x fouten bevat. Het compileerde de kernel ook nog niet.

[..]
Ow? Maar dat is wat me juist wel gelukt is, het compileren van de kernel.
Misschien dat ik dat over moet doen met deze versie van gcc want ik heb weinig zin ik verrassingen.

Taaaa taa taa taaaa taa taa ta taaataaaaa.


Verwijderd

Op zondag 02 juni 2002 21:21 schreef Valium het volgende:
Dus geen geklaag over de mensen van Mplayer. Ze hebben gelijk. 2.96 is bedroevend brak en 3.0 is ook nog vrij brak. 3.1 is goed.
In linux multimedia land wordt hier over het algemeen iets anders tegenaan gekeken... Buiten het mplayer ontwikkelkamp zijn de mplayer mensen niet echt populair vanwege deze acties... :X.
Op zondag 02 juni 2002 14:37 schreef foser het volgende:
Die gozers weten wel waar ze mee bezig zijn
Daarover verschillen de meningen in linux multimedia land dus nogal... :X.
dus die hebben 't volste recht om te zeggen wat te gebruiken en wat niet.
Ik zou bijna zeggen dat dat op Microsoft gedrag begint te lijken...

  • Valium
  • Registratie: Oktober 1999
  • Laatst online: 09-08 08:59

Valium

- rustig maar -

Op zondag 02 juni 2002 23:43 schreef beelzebubu het volgende:
[..]
In linux multimedia land wordt hier over het algemeen iets anders tegenaan gekeken... Buiten het mplayer ontwikkelkamp zijn de mplayer mensen niet echt populair vanwege deze acties... :X.
Het zijn botte boeren. Dat is ontzettend jammer. Maar bekijk het eens van hun kant. Zwaar optimaliseren aan de ene kant, maar het moet wel werken met kapotte compilers. :?
Daarover verschillen de meningen in linux multimedia land dus nogal... :X.
[..]

Ik zou bijna zeggen dat dat op Microsoft gedrag begint te lijken...
Niet gaan overdrijven he? Als het je niet aanstaat pas je toch de sourcecode van mplayer aan zodat het wel werkt. Niemand houdt je tegen (itt de M$-praktijken). Het zijn misschien ontzettende eikels, maar ik kan ze ook geen ongelijk geven. Al had ik het liever gehad dat het wel zou werken natuurlijk.

Verwijderd

Op zondag 02 juni 2002 21:21 schreef Valium het volgende:<KNIP>

Verder is het bekend dat GCC 3.0.x fouten bevat. Het compileerde de kernel ook nog niet. Die problemen zouden er in 3.1 uit gehaald moeten zijn. En jawel hoor. 3.1 compileert alles zonder problemen. Ik heb zelf ook al XFree86 met 3.1 gecompileerd (meerdere keren zelfs) en het werkt probleemloos.

<KNIP>
Ben ik het niet mee eens. GCC 3.1 compileert veel, maar absoluut niet alles. Ik krijg de kernel normaal gesproken netjes gecompileerd, maar heb er een MOSIX patch over gegooid, en voila.. Niet meer compileren. Hetzelfde geldt voor de CVS versie van KDE (multimedia stuk). GCC 2.95.3 (zoals standaard in Slack) doet het prima, GCC 3.1 loopt erop stuk.... Such is life, denk ik. Ik denk wel dat de jongens (en meiden?) van Mplayer hun vereisten mogen neerleggen, want dat doen andere ontwikkelaars tenslotte ook (specifieke versies van autoconf, automake, bepaalde versies van specifieke libraries, etc...). Ze mogen alleen wel een cursusje diplomatie volgen, maar da's mijn persoonlijke mening... :)

  • RG
  • Registratie: Augustus 2000
  • Laatst online: 28-11-2025

RG

Lambda

Die programma's kunnen de compiler wel de schuld geven, maar als iets onder GCC 3.1 niet werkt kan je over het algemeen wel zeggen dat iets niet bepaald netjes is geprogrammeerd. GNOME2 bijvoorbeeld werkt bij mij al probleemloos met GCC 3.0.3. En dat terwijl het toen nog zwaar in development was. Dus het is ook gewoon een kwestie van nette code schrijven en geen kunstgrepen uithalen die de compiler dan als warning oid aanduidt.
Er liggen trouwens meer problemen bij C++ code dan bij C code volgens mij, omdat vooral bij C++ code minder dingen worden toegestaan (weet ik niet helemaal zeker). O.a. aRtsd wil daarom nog niet compileren...

[deze advertentieruimte is te koop]


Verwijderd

Op maandag 03 juni 2002 14:12 schreef RG© het volgende:
Die programma's kunnen de compiler wel de schuld geven, maar als iets onder GCC 3.1 niet werkt kan je over het algemeen wel zeggen dat iets niet bepaald netjes is geprogrammeerd. GNOME2 bijvoorbeeld werkt bij mij al probleemloos met GCC 3.0.3. En dat terwijl het toen nog zwaar in development was. Dus het is ook gewoon een kwestie van nette code schrijven en geen kunstgrepen uithalen die de compiler dan als warning oid aanduidt.
Er liggen trouwens meer problemen bij C++ code dan bij C code volgens mij, omdat vooral bij C++ code minder dingen worden toegestaan (weet ik niet helemaal zeker). O.a. aRtsd wil daarom nog niet compileren...
Hmmm.. Ach.. Ik denk dat het met optimaliseren of met het oog op een bepaalde (familie van) compiler(s) programmeren is. Verder compiled aRtsd perfect onder 3.1 hoor... Ik heb alleen problemen met KDEMultimedia uit de CVS :(

Verwijderd

Op maandag 03 juni 2002 01:01 schreef Valium het volgende:
Het zijn botte boeren. Dat is ontzettend jammer. Maar bekijk het eens van hun kant. Zwaar optimaliseren aan de ene kant, maar het moet wel werken met kapotte compilers. :?
Wie zegt dat de compiler kapot is? Zij? Geloof jij dat? En geldt datzelde niet ook (in mindere mate) voor 2.95? Die heeft ook nog bugs!

Optimaliseren is geen argument, dat doe je namelijk met netgeschreven code of met assembler. Wat zij deden (in het verleden - nu misschien nog steeds) is rampzalig gestructureerde en opgemaakte code schrijven. Nu kun je de interpreter van gcc de schuld wel geven, maar je kunt net zo goed de opmaak van je code wat netter maken. Geoptimaliseerde code schrijf je in assembler en dat compileert nasm normalitair. Als je hele lappen asm in c files stopt is dat al fout op zich.

De compiler is niet kapot, de compiler is alleen niet perfect. En daar kun je omheen werken, dat doet ieder project (vaak zonder dat ze het zelf doorhebben). Waarom zouden de goden van het goddelijke mplayer een speciale status hebben en zich mogen verheffen boven de rest en gewoon roepen dat het de taak van gcc is om hun code te inrepreteren in plaats van zelf intepreteerbare code te schrijven?

Het lijkt de omgekeerde wereld wel!
Niet gaan overdrijven he? Als het je niet aanstaat pas je toch de sourcecode van mplayer aan zodat het wel werkt. Niemand houdt je tegen (itt de M$-praktijken). Het zijn misschien ontzettende eikels, maar ik kan ze ook geen ongelijk geven. Al had ik het liever gehad dat het wel zou werken natuurlijk.
Ik wil niet met hun code werken. Ik werk met gestandaardiseerde, gesharede, goed-gestructureerde, goed-gedocumenteerde en goed-werkende code.

Verwijderd

Tsja.. en dat is een goed onderbouwde mening waar ik weinig tegen in kan brengen :)

Verwijderd

Op maandag 03 juni 2002 18:01 schreef beelzebubu het volgende:

[..]

Wie zegt dat de compiler kapot is? Zij? Geloof jij dat? En geldt datzelde niet ook (in mindere mate) voor 2.95? Die heeft ook nog bugs!

Optimaliseren is geen argument, dat doe je namelijk met netgeschreven code of met assembler. Wat zij deden (in het verleden - nu misschien nog steeds) is rampzalig gestructureerde en opgemaakte code schrijven. Nu kun je de interpreter van gcc de schuld wel geven, maar je kunt net zo goed de opmaak van je code wat netter maken. Geoptimaliseerde code schrijf je in assembler en dat compileert nasm normalitair. Als je hele lappen asm in c files stopt is dat al fout op zich.

De compiler is niet kapot, de compiler is alleen niet perfect. En daar kun je omheen werken, dat doet ieder project (vaak zonder dat ze het zelf doorhebben). Waarom zouden de goden van het goddelijke mplayer een speciale status hebben en zich mogen verheffen boven de rest en gewoon roepen dat het de taak van gcc is om hun code te inrepreteren in plaats van zelf intepreteerbare code te schrijven?

Het lijkt de omgekeerde wereld wel!
[..]

Ik wil niet met hun code werken. Ik werk met gestandaardiseerde, gesharede, goed-gestructureerde, goed-gedocumenteerde en goed-werkende code.
Hmmm.... Heb je Xine of VideoLAN dan al overwogen dan? Zeker waardige alternatieven voor mplayer. :)

Verwijderd

Op dinsdag 04 juni 2002 12:14 schreef motown het volgende:
Hmmm.... Heb je Xine of VideoLAN dan al overwogen dan? Zeker waardige alternatieven voor mplayer. :)
Xine gebruik ik inderdaad - erg mooi programma. Ik gebruik mplayer ook wel - maar ik zal er nooit aan meeprogrammeren. Ik programmeer aan de GStreamer Media Player (in Gnome 2.2 de Gnome Media Player).
Pagina: 1