MPLAYER: Error beim Kopilieren

Hi,
wollte mich gerade dran machen den mplayer strikt nach c't Anleitung zu kompilieren. Bis zum runterladen aller benötigten Sourcen ging auch alles glatt. Dann aber, nach dem 'debian/rules binary' hagelte es Fehlermeldungen a la:

# commands to compile the package.
/usr/bin/make
make[1]: Entering directory `/var/src/mplayer/MPlayer-1.0pre5'
/usr/bin/make -C postproc
make[2]: Entering directory `/var/src/mplayer/MPlayer-1.0pre5/postproc'
cc -c -I../libvo -I../../libvo  -O4 -march=i486 -mcpu=i686 -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/linux/dvb   -I. -I.. -I/usr/include/linux/dvb  -I.. -o swscale.o swscale.c
cpp0: output pipe has been closed
{standard input}: Assembler messages:
{standard input}:8839: Warning: end of file not at end of a line; newline inserted
{standard input}:10176: Error: suffix or operands invalid for `jge'
cc: Internal compiler error: program cc1 got fatal signal 11
make[2]: *** [swscale.o] Error 1
make[2]: Leaving directory `/var/src/mplayer/MPlayer-1.0pre5/postproc'
make[1]: *** [postproc/libswscale.a] Fehler 2
make[1]: Leaving directory `/var/src/mplayer/MPlayer-1.0pre5'
make: *** [build-stamp] Fehler 2

Ich denke entscheidend sind die Fehler mit {standard input}, u.U. geht dem compiler das memory aus. Habe versucht das mittels swap-erweiterung zu kompensieren, ohne Erfolg. Zunächst tauchte der Fehler immer erst nach einigen kompilierten Modulen auf. Ein erneuter Aufruf des Prozesses machte dann an der Stelle weiter wo der Fehler vorher auftrat. Nun aber scheiter bereits das erste Modul und ich komme nicht weiter.

Für Tips bin ich sehr dankbar, wie ihr euch vorstellen könnt, denn ohne mplayer keine DVDs etc.

Hi slime,

ich habe 512 MB in der Kiste, deswegen war ich auch anfangs verblüfft. Da es aber immer nach dem abarbeiten von 5-10 Objekten auftrat lag der Schluss nahe. Free gibt mir aber VOR dem kompilierren:

total used free
Mem: 515296 67216 448080

und danach:

Mem: 515296 72388 442908

Also gut, das spricht eigentlich eher gegen die Theorie, zugegeben.

[RATLOS]
Aber was dann? Ich meine Pakete zu kompilieren gehört eigentlich zu den Basics! Das läuft immer!

@ armageddon

Hmm, es handelt sich immerhin um einen Athlon XP 1800. Der ist sonst eigentlich nur mit Warten beschäftigt. Und das bißchen kompilieren sollte ihn eigentlich nicht jucken. Der Rechner war bis vor einem halben Jahr mein Bürorechner. Da gab es eigentlich keine Probleme mit Abschmieren und so weiter. Und wie gesagt er schmiert ja auch nicht ab, nach der Fehlermeldung kann ich sofort neu anfangen und es geht ein paar Module weiter, jedenfalls bis zu diesem besagten libswscale.o.

Hab jetzt aber immerhin nochmal nach dem "signal 11" geforscht und siehe da:

SIGSEGV    |   11 | C      | Ungültige Speicherreferenz, wobei


 C      Normalerweise wird ein "dump core" durchgeführt.

Es wird immer rätselhafter. Ich meine ich mach ja hier nichts weiter als Brot und Butter Sachen, keine exotischen Experimente. Warum sollte der Compiler einen SEGV produzieren.

@ catweazle:

Werd mich morgen dranmachen. Muß jetzt los.

@ slime

Das wird eine längere Sache wenn ich jetzt den gcc debugge

Aber inzwischen habe ich eine nette page mit dem Titel
"The SIG11 problem"

http://www.bitwizard.nl/sig11/</a><br>
gefunden, die die Sache bis ins kleinste Detail erklärt und... meint mein RAM wäre eventuell unstable. Werde morgen also mal einen RAM-Tausch probieren.

Danke jedenfalls mal für den Beistand bislang.

Hi und danke nochmal,

habe heute morgen den Rechner eingeschaltet, nachdem ich ihn die ganze Nacht aushatte und siehe da, der Compilerlauf ging durch. Allerdings gab es von gestern noch zu viele defekte .o's und der Linker meckerte. Einen zweiten, kompletten, Compilerlauf hielt er schon wieder nicht durch, also scheint der Bitwizard doch mit seinem Tip richtig zu liegen. Immerhin gibt es im laufenden Betrieb keine Ausfälle zu beklagen. Sollte es mir also gelingen den mplayer zu kompilieren, kann ich mir für die endgültige Problemlösung Zeit lassen.

Vielen Dank jedenfalls an slime und armageddon!