Kompilieren (LinuxGentoo)
Aus PantheonWiki
Stand: 8.9.2008
Es gibt Pakete (Ebuilds) für Rastullahs Lockenpracht zum automatisierten Kompilieren unter Gentoo. Von manchen Paketen werden Entwicklerversionen aus CVS/SVN benötigt, die Ebuilds installieren in diesen Fällen bestimmte Entwicklungsstände direkt aus den Repositories. Die Versionsangabe des Ebuilds entspricht hierbei der Subversion-Revisionsnummer bzw. dem Datum bei CVS
RL sowie all seine Abhängigkeiten, die nicht im offiziellen Portage-Tree von Gentoo sind, sollten in diesem Tarball enthalten sein: Download rastullah-overlay.tar.gz
Hinweis: Die Ebuilds wurden von ein paar Leuten getestet, aber es können trotzdem unerwartete Fehler auftreten. Feedback ist natürlich erwünscht.
In dem heruntergeladenen Tarball steckt ein "Overlay"-Verzeichnis, das genau so organisiert ist wie der lokale Portage-Tree (üblicherweise /usr/portage). Das Konzept von einem Overlay ist, dass man ihn leicht dem Paketsystem hinzufügen kann und alle Ebuilds, also Pakete, darin z.B. mit dem altbekannten Tool emerge verwaltet werden können. Dadurch werden nicht nur die Abhängigkeiten größtenteils automatisch erkannt und vorinstalliert, sondern man kann die Pakete leicht updaten, sauber deinstallieren, etc.
Inhaltsverzeichnis |
Schritt 1: Overlay installieren
Nachdem man den Tarball heruntergeladen hat, entpackt man ihn an einer Stelle seiner Wahl (hier: /usr/local/rastullah-overlay)
# mkdir /usr/local/rastullah-overlay # cd /usr/local/rastullah-overlay # tar xvzf rastullah-overlay.tar.gz
Das entstandene Overlay-Verzeichnis trägt man nun in der /etc/make.conf ein (einfach die Zeile der Datei anfügen, wenn PORTDIR_OVERLAY noch nicht definiert ist):
PORTDIR_OVERLAY="/usr/local/rastullah-overlay"
Wenn man schon einen Overlay benutzt: durch ein Leerzeichen trennen, z.B.:
PORTDIR_OVERLAY="/usr/local/portage /usr/local/rastullah-overlay"
Schritt 2: Portage konfigurieren
Einige der Abhängigkeiten müssen mit bestimmten USE-Flags kompiliert sein. Um die Flags dauerhaft einzutragen muss man in der Datei /etc/portage/package.use (als normale Textdatei erstellen, falls nicht schon vorhanden) folgende Einträge machen:
dev-games/cegui xerces-c devil dev-games/ogre cegui cg freeimage dev-lang/ruby doc threads dev-lang/swig ruby
und die Pakete ggf. neubauen. Der rastullah-Ebuild enthält auch Checks, ob die Abhängigkeiten mit den richtigen Flags gebaut wurden, aber Portage baut leider nicht automatisch Pakete mit anderen USE-Flags neu, daher bricht ein Ebuild an der Stelle mit einer aussagekräftigen Meldung ab.
Desweiteren gibt es immer mal wieder Probleme mit aktuellen Versionen in Portage. Beispiel SWIG die selbstgepatchte Version 1.3.31 funktioniert, allerdings ist mittlerweile schon eine neuere Version in Portage. Da man nicht immer daran denken müssen will, explizit 1.3.31 zu verwenden...
# emerge =swig-1.3.31
... kann man die neueren Pakete durch einen Eintrag in der /etc/portage/package.mask maskieren:
>dev-lang/swig-1.3.31
Das verhindert, dass z.B. bei einem Systemupgrade neuere Versionen installiert werden. Sobald es eine funktionierende Version im offiziellen Portage gibt, sollte man diesen Eintrag wieder entfernen.
Schritt 3: Rastullahs Lockenpracht kompilieren
Kurze Erklärung: Die Pakete aus dem RL-Overlay sind alle als "unstable" markiert und werden normalerweise (ohne ACCEPT_KEYWORDS) nicht installiert. Wenn man nicht immer ACCEPT_KEYWORDS manuell setzen will, sollte man folgendes in seine /etc/portage/package.keywords eintragen:
dev-games/cegui ~x86 dev-games/newton ~x86 dev-games/ogre ~x86 dev-games/ogrenewt ~x86 dev-games/ois ~x86 dev-games/opensteer ~x86 games-rpg/rastullah ~x86 games-rpg/rastullah-modules ~x86 media-libs/fmod ~x86 media-libs/freeimage ~x86 media-libs/meshmagick ~x86
Alternativ kann man auch folgendes eintippen:
# ACCEPT_KEYWORDS="~x86" emerge rastullah
Das ist zwar ein schöner, griffiger Befehl, aber durch Abhängigkeiten bekommt man so evtl. andere instabile Pakete mit, die man eigentlich gar nicht will. Außerdem muss man ACCEPT_KEYWORDS bei jedem Update von Hand setzen. Daher würde ich wirklich die Verwendung von /etc/portage/package.keywords empfehlen.
Wenn man gleich alle spielbaren Module (Achtung, ein paar Hundert MB Download!) mitinstallieren will, kann man ein entsprechendes USE-Flag davorstellen. Dies installiert das Paket "rastullah-modules" zusätzlich, welches eigentlich nur aus dem Modulverzeichnis aus dem SVN besteht und in der Standardlocation (definiert in der rastullah.conf, mehr dazu siehe unten) abgelegt wird:
# USE="modules" emerge rastullah
Schritt 4: Rastullahs Lockenpracht starten
Die Spielmodule von RL sind in ein eigenes Paket ausgegliedert, mit dem rastullah-USE-Flag "modules" wird dieses gleich nach /usr/share/games/rastullah installiert (Gentoo-Konvention). Ansonsten kann man es nachträglich installieren mit:
# emerge rastullah-modules
Auch dieses Paket unterstützt USE="latest" zum Installieren der aktuellsten SVN-Version. Das Paket ist optional und vor der Installation wird man dazu aufgefordert, die Lizenzbestimmungen zu akzeptieren, da die Moduldaten nicht unter einer freien Lizenz stehen. Man kann aber auch einfach eine lokale Kopie des SVN-Repositories auschecken und diese bequem aktualisieren, und z.B. einen Symlink /usr/share/games/rastullah anlegen, der auf das ausgecheckte Verzeichnis zeigt. Beispiel:
# ln -s /usr/local/src/dsa-hl/modules /usr/share/games/rastullah
/usr/share/games/rastullah ist der Standardpfad unter Gentoo, der in die rastullah.conf eingetragen wird - dieser lässt sich natürlich auch anpassen.
Am Ende der Installation von RL wird schon darauf hingewiesen, dass der ausführende Benutzer in der Gruppe "games" sein muss - denn RL wird so installiert, dass nur "games"-Gruppenmitglieder es spielen dürfen. Also darauf achten, bevor man folgendes eintippt:
$ RUBYLIB=/usr/games/lib rastullah
Wenn das klappt, Glückwunsch. RUBYLIB kann man sich z.B. in seine .bashrc eintragen (echo "export RUBYLIB=/usr/games/lib" >> ~/.bashrc), dann reicht auch nur "rastullah" zum Starten. Außerdem sollte LANG bzw. LC_ALL auf irgendetwas Vernünftiges gesetzt sein, sonst stößt man relativ schnell auf einen locale-Fehler.
Tips & Tricks
Aktuellste Version verwenden
Die Ebuilds, die CVS oder SVN benutzen, haben noch ein nettes USE-Flag namens "latest". Mit diesem checken sie aus CVS bzw. SVN stur die aktuelle HEAD-Version aus; will heissen, es gibt aber auch gar keine Garantie, dass die ausgecheckte Version funktioniert (die Ebuilds verwenden ohne das Flag immerhin Revisionen, die schon einmal erfolgreich getestet wurden). Aber zum automatisierten Testen sicher brauchbar. Kleines Beispiel:
# USE="latest" emerge rastullah
ccache
ccache speichert die Objektdateien, die als Zwischenschritte beim Kompilieren entstehen, ab und kann sie beim nächsten Kompilieren wiederverwenden (wenn sich nichts daran geändert hat). Das spart unter Umständen enorm viel Zeit beim Neukompilieren alter Pakete. Nachteil: es verbraucht ordentlich Speicherplatz auf der Festplatte (500 MB verwendet ccache standardmäßig, aber empfehlenswert sind 2 GB). Um ccache zu verwenden, reichen 2 Zeilen in der /etc/make.conf:
FEATURES="ccache" CCACHE_SIZE="2G"
Debugging
Um unter Gentoo vernünftig debuggen zu können, muss man die Variable FEATURES setzen, denn Portage führt normalerweise strip aus um die entstehenden Binärdateien kleiner und schneller zu machen. Außerdem gibt es ein USE-Flag namens "debug", das configure mit --enable-debug aufruft und den Rest erledigt.
# FEATURES="nostrip" USE="debug" emerge rastullah
Eventuell reicht rastullah alleine nicht aus, denn der Fehler kann ja auch in einer der Abhängigkeiten liegen. Falls man in der /etc/make.conf CFLAGS und CXXFLAGS auf etwas ungünstiges gesetzt hat, sollte man dem Ganzen noch beide Variablen mit leeren Werten davorstellen.
Kleines Beispiel um mit dem gdb einen Backtrace von einem Speicherzugriffsfehler zu erzeugen:
$ gdb rastullah (gdb) run (gdb) bt
Troubleshooting
Segmentation fault kurz nach dem Starten und kein brauchbarer Backtrace
Symptom:
(gdb) run Starting program: /usr/local/bin/rastullah Failed to read a valid object file image from memory. [Thread debugging using libthread_db enabled] [New Thread -1250765136 (LWP 5978)] Checking for rastullah.conf in ./ Checking for rastullah.conf in /etc/rastullah/ Adding path /etc/rastullah/ to Rastullah configuration path. Checking for rastullah.conf in /home/twel/.rastullah/ Loading Configuration File /etc/rastullah/rastullah.conf /usr/lib/OGRE/RenderSystem_GL /usr/lib/OGRE/Plugin_ParticleFX /usr/lib/OGRE/Plugin_OctreeSceneManager Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1250765136 (LWP 5978)] 0xb5854054 in ?? () from /lib/libc.so.6 (gdb) bt #0 0xb5854054 in ?? () from /lib/libc.so.6 #1 0xb5915120 in ?? () from /lib/libc.so.6 #2 0xb5915130 in ?? () from /lib/libc.so.6 #3 0xb5915144 in ?? () from /lib/libc.so.6 #4 0x00000001 in ?? () #5 0xb5915150 in ?? () from /lib/libc.so.6 #6 0x00000000 in ?? ()
Auch mit --enable-debug und FEATURES=nostrip kam kein vernünftiger Backtrace zu Stande. Das Problem tauchte immer wieder auf und es lag gar nicht an RL, sondern an Ogre, welches mit USE=threads kompiliert wurde. --enable-threading wird vom Ogre-configure "experimentell" genannt, und das ist es offenbar.
Access Violation beim ersten mal Auschecken von SVN
Ein "mkdir"-Aufruf innerhalb der Sandbox scheiterte mit einer knallroten Access Violation. Das Verzeichnis /usr/portage/distfiles/svn-src sollte vom ersten SVN-Ebuild angelegt werden. Das Problem lässt sich umschiffen, in dem das Verzeichnis von Hand mit
# mkdir /usr/portage/distfiles/svn-src
anlegt und emerge neustartet ("emerge --resume").
