Manchmal ist Film gucken einfach nur schön. Aber wenn einem der Player bereits im Vorspann mit einer Fehlermeldung wegschmiert, ist das einfach nur nervig. So letztens mit dem VLC geschehen.Doch woher kam das Problem?
Da ich nicht die neuste Version installiert hatte, hab ich also ein Update von 0.9.4 auf 0.9.6 ausgeführt und gleich auch die Konfiguration zurückgesetzt – sicher ist sicher. doch auch hier tat sich nichts. Also beschloss ich, mich einmal im Playback des VLC mit einem Debugger einzuklinken. Gesagt getan – und ich stellte fest, ich hätte es lassen sollen. Ich fand zwar ziemlich schnell die Stelle im Speicher, die hin zu diesem Fehler führte, doch mehr auch nicht, da keine Debug-Informationen für die Release-Versionen verfügbar waren.
Daraufhin bin ich losgezogen und hab einmal versucht, für ein gegebenes Release Debug-Informationen aufzutreiben. Auf der Website gab es diese jedenfalls nicht und auch das Wiki der VideoLAN-Leute offenbarte nur eins: Wer Debug-Informationen brauch, muss n Nightly Build nehmen oder selber bauen.
Schauen wir uns also beide Alternativen einmal an:
Da wäre ersteinmal das Nightly Build. Dieses ist automatisch generiert und enthält Debug-Informationen. Diese können aber nicht von OllyDbg oder anderen gängigen Debuggern unter Windows gelesen werden. Alleinig die MinGW-Tools können ansatzweise Aufschluss über die Aussage dieser knapp 20 MB Zusatzlast geben. Wäre ja nicht so schlimm, wenn es denn wenigstens Debug-Informationen für 0.9.x-Releases gäbe; aber diesen Luxus hat man nur mit 1.0.x-Releases, die bei mir nicht starten wollten.
Bleibt also die Möglichkeit „selber bauen“, die ich jedem Masochisten nur wärmstens ans Herz legen kann. Unter Windows ein Windows-Build zu erzeugen wird in der Wiki zwar erwähnt, dass dies nativ mit MinGW irgendwie funktioniert, aber eine nähere Beschreibung bleibt einem die Wiki schuldig. Cygwin wird zwar alternativ erwähnt und besitzt sogar eine eigene Informationsseite, da man aber mit CygWin ein halbes Linux installiert, kann man auch gleich auf Linux wechseln und für Windows cross-compilieren.
Gesagt, getan! Von einem der Entwickler des VLC erhielt ich dabei sogar in Form eines kleinen VirtualBox-Images, in dem jegliche benötigten Dinge vorkonfiguriert waren, einige Unterstützung. Das Image an sich fuhr sauber hoch und die Arbeit konnte losgehen.
Nach dem Konfigurieren mit
./configure
lief soweit alles durch und auch das Bauen mit
./compile
funktionierte augenscheinlich fehlerfrei. Da das ./configure jedoch für Linux war, brachte mir das erstmal recht wenig. Also gesucht, wie das mit Cross-Compiling zu konfigurieren geht und die benötigte Option –host=i586-windows gefunden. Neu ge-configure-d und ge-make-d, schien zwar durchzulaufen, aber richtig, sah’s Ergebnis nicht aus.
Also auf, zum nächsten Versuch: Was sagt ein etwas neueres Build direkt aus dem HEAD? Also ein kurzes
git stash
git pull --rebase
git stash apply
ausgeführt, um mir eben diesen Code aus der Versionsverwaltung zu holen. Wieder einmal ge-configure-d und versucht zu make-n, meckerte make herum, dass es einige Dateien nicht finden kann. Fehlte noch das
./bootstrap
um Automake zu sagen, dass es mal bitte seine ganzen Makefiles neu erstellen soll. Mit diesem Schritt kam ich schon mal einen Schritt weiter: Make meckerte jetzt nicht mehr über eine fehlende Makefile, dafür meckerte jetzt aber ld über einen ganzen Haufen von undefinierten Einsprungpunkten. Gut, dies lag sicherlich am statischen Anbinden der Teilbibliotheken – also diesmal alles shared gelinkt und siehe da: Er meckert wo anders!
Die einzig brauchbare Option für VLC ist folgende Makefile – vielleicht nehmen die Entwickler diese ja in neue Releases noch auf:
diskclean:
rm -fr .
Diese Option sollte eine ganze Reihe der Probleme beim Compilieren des VLC beheben …
Zumindest für heute geb ich erstmal meinen Versuch, den VLC anständig zu debuggen auf. Vielleicht ein anderes Mal noch mal einen Versuch. Für jetzt reicht es mir erstmal! Und da wollte ich doch nur gemütlich Film gucken …
