Quelltextarchive¶

Quelltexte werden entweder in einem Archiv (meist tar) zum Download angeboten, oder können direkt über eine Versionsverwaltung bezogen werden. Nach dem Download muss das Archiv im Homeverzeichnis^[7] entpackt werden^[4]. Dazu bietet es sich an, dort ein beliebiges Arbeitsverzeichnis wie z. B. ~/Quelltexte/ anzulegen. Entpackt man das Archiv dorthin, dann wird normalerweise ein weiteres Unterverzeichnis mit dem Programmnamen und oftmals auch der Versionsnummer angelegt - z. B. programmname-0.1.0/. Dieses Verzeichnis ist der Ort, an dem die gesamten hier erklärten Methoden ausgeführt werden und wird von hier an als "Quelltextverzeichnis" bezeichnet.

Falls das Quelltextarchiv beim Entpacken nicht in einen einzelnen neuen Ordner innerhalb des Arbeitsverzeichnisses entpackt wurde, sollte dies nachgeholt werden, indem ein neuer Order, z. B. programmname-0.1.0/, erstellt wird und dort hinein der gesamte entpackte Quelltext verschoben wird.

Dokumentation¶

Alle nötigen Informationen für das Kompilieren und Installieren lassen sich in der Regel direkt im Quelltextverzeichnis finden, oder aber auf der Entwicklerseite des jeweiligen Programms. Im Quelltextverzeichnis befinden sich Textdateien wie README, INSTALL, BUILD o.ä., die weiterführende Informationen zu den Abhängigkeiten und Konfigurationsoptionen, sowie Installationsanweisungen enthalten.

Terminal¶

Auch wenn das Terminal^[3] sehr ausführlich in seinem eigenen Artikel behandelt wird, sei an dieser Stelle noch einmal auf einen Umstand hingewiesen, der sich gerade für Anfänger beim Kompilieren als unerwartete Fallgrube erweisen kann. Startet man das Terminal, so wird in der Befehlszeile das Homeverzeichnis^[7] als Arbeitsverzeichnis gesetzt. Bevor man also einen Quelltext kompilieren kann, muss man erst in das Quelltextverzeichnis wechseln und von dort arbeiten.

Abhängigkeiten für eine neue Paketversion¶

Möchte man kein neues Programm, sondern nur eine neuere Version eines bereits in den Paketquellen^[8] vorhandenen Pakets kompilieren, dann lässt sich diese Hürde mit einem einfachen Befehl im Terminal^[3] nehmen, der automatisch die im Normalfall nötigen Abhängigkeiten installiert.

sudo apt-get build-dep PAKETNAME 

sudo aptitude build-depends PAKETNAME 

Abhängigkeiten für ein neues Programm¶

Beim Kompilieren eines Programms, das nicht in den Paketquellen^[8] vorhanden ist, gestaltet sich dieser Schritt etwas schwieriger. Die Auflistung der Abhängigkeiten in der Dokumentation ist oftmals sehr allgemein gehalten, was das Auflösen der Abhängigkeiten unter Umständen zu einem Ratespiel werden lässt.

Prinzipiell kann man zwischen fünf verschiedenen Arten von Abhängigkeiten unterscheiden:

1. Programme für das Kompilieren und Installieren wie der Compiler oder das Build-System.

2. Entwicklerdateien ("Development Files") von Bibliotheken für das Kompilieren. Solche Bibliotheken sind in der Regel durch das Präfix lib für "Library" und das Suffix -dev für "Development" gekennzeichnet.

3. Entwicklerdateien von Programmen für das Kompilieren. Entsprechende Pakete für diese Programme sind mit dem Suffix -dev gekennzeichnet.

4. Programme, auf denen das zu kompilierende Programm aufbaut und ohne die bestimmte Funktionen nicht ausführbar wären.

5. Bibliotheken, auf denen das zu kompilierende Programm aufbaut. Entsprechende Pakete lassen sich am Präfix lib erkennen und werden bei der Installation der Entwicklerdateien (#2) automatisch als Abhängigkeit mitinstalliert.

Ein Beispiel:

In der Dokumentation steht die Abhängigkeit "GTK+ >= 3.6" oder "gtk+-3.0 >= 3.6", dann ist gemeint, dass für das Ausführen des Programms libgtk-3-0 größer oder gleich der Version 3.6 benötigt wird und für das Kompilieren libgtk-3-dev. Die Installation von libgtk-3-dev würde als Abhängigkeit dann die Installation von libgtk-3-0 mit sich ziehen.

Fehlende Pakete oder falsche Paketversion¶

Sollte ein Paket der Abhängigkeiten nicht in den Paketquellen^[8] vorhanden sein, dann wird man sich zum Quelltext des eigentlichen Programms noch zusätzlich den Quelltext des fehlenden Pakets herunterladen, kompilieren und installieren müssen.

Bei einem Paket in den Abhängigkeiten, welches in den Paketquellen in einer falschen Programmversion vorliegt (also einer zu alten oder zu neuen), bewegt man sich langsam auf einen kritischen Punkt zu. Da auch andere Pakete von diesem Paket abhängen können (siehe rdpends), würde das Installieren der nötigen Version möglicherweise zu Beeinträchtigungen bei anderen Programmen und somit auch zu Beeinträchtigungen der Systemstabilität führen.

• Neuere Programmversionen stellen dabei ein geringeres Risiko dar, weil die Paketquellen von Ubuntu verhältnismäßig aktuelle Programme und Bibliotheken enthalten. Die Änderungen in einer neueren Paketversion könnten also recht klein ausfallen und auch andere Pakete, die davon abhängen, nicht in Mitleidenschaft ziehen.

• Von der Installation älterer Paketversionen ist in diesem Zusammenhang prinzipiell eher abzuraten. Die Wahrscheinlichkeit von Beeinträchtigungen sind dabei ziemlich hoch. Programme, die solche alten Programmversionen in den Abhängigkeiten haben, werden meistens nicht mehr aktiv gepflegt und bräuchten sinnvoller Weise eine Überarbeitung des Quelltextes.

Handelt es sich um eine qualitativ hochwertige Bibliothek, kann man am SONAME und damit direkt am Paketnamen erkennen, ob verschiedene Versionen zueinander kompatibel sind. Der SONAME ist eine Versionszeichenkette, wie z. B. "libgtk-3.so.0" bzw. "libQtCore.so.4". Versionen mit gleicher Hauptversion ("major version") zeigen an, dass sie zueinander abwärtskompatibel sind. Die Debian-Paketnamen sind nach dem Schema "lib|BIBLIOTHEKNAME|MAJOR_VERSION-MINOR_VERSION" (ohne "|") aufgebaut, somit sieht man direkt was zueinander kompatibel ist (oder zumindest sein soll).

Bei versionierten Abhängigkeiten sollte man sorgfältig abwägen, inwieweit Aufwand und Risiko durch den Nutzen des Programms wett gemacht werden.

Konfigurieren¶

Der folgende Befehl startet ein Skript, das überprüft, ob das Programm mit der aktuellen Systemumgebung kompatibel ist, alle Abhängigkeiten aufgelöst wurden und setzt gegebenenfalls systemspezifische Optionen im Makefile für den Compiler. Weitere Optionen für das configure-Skript werden am Ende des Abschnitts behandelt.

./configure 

Dieses configure-Skript ist nicht unbedingt immer vorhanden. So kommt es bei weniger umfangreichem Quelltext wie bei Plugins häufiger vor, dass sie unkonfiguriert kompiliert werden können und die Installation dann lediglich darin besteht, das kompilierte Plugin in das richtige Verzeichnis zu kopieren. configure-Skripte werden meist mit dem "autotools"-Build-System erstellt. Es gibt jedoch auch andere Systeme, bei denen die Konfiguration anders erfolgt. Diese werden in Programme_kompilieren/Alternativen: Abweichende Methoden behandelt.

./autogen.sh 

checking for C compiler default output file name...
configure: error: C compiler cannot create executables

checking for ALSA... configure: WARNING: Package alsa was not found in the pkg-config search path.
Perhaps you should add the directory containing `alsa.pc'
to the PKG_CONFIG_PATH environment variable
No package 'alsa' found

configure: error: Library requirements (gtk+-2.0 >= 2.4.0 glib-2.0 >= 2.4.0 atk >= 1.0 pango >= 1.0 libglade-2.0 >= 2.4.0) not met;
consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them.

apt-file -l find libgtk | grep dev 

checking for xmms-config... no
checking for XMMS - version >= 1.2.4... no
configure: WARNING: *** XMMS >= 1.2.4 not installed - please install first ***

./configure --prefix=/usr/local 

./configure --help 

Kompilieren¶

Ist das configure-Skript fehlerfrei durchgelaufen, startet der eigentliche Kompiliervorgang mit folgendem Befehl:

make 

Je nach Programmgröße und Rechenleistung kann der Kompiliervorgang etwas länger dauern.

/usr/bin/ld: cannot find -lXtst

apt-file -l find libxtst | grep dev 

Installieren¶

Nachdem make fehlerfrei durchgelaufen ist, erfolgt die Installation hier mit checkinstall. Dazu muss das gleichnamige Paket installiert^[1] werden:

• checkinstall (universe)

mit apturl

sudo apt-get install checkinstall 

sudo aptitude install checkinstall 

Der Vorteil mit checkinstall (oder nach der Debian-Methode) zu installieren ist, dass ein Programm nicht an der Paketverwaltung^[1] vorbei installiert wird, sondern ein Paket im Quelltextverzeichnis erstellt und automatisch installiert wird.

Zum Aufruf von checkinstall folgenden Befehl ausführen:

sudo checkinstall 

Das Programm bietet jetzt einige Einstellungsmöglichkeiten für die Paketmetainformationen:

• Die Frage nach dem Erstellen eines Standardsatzes "docs" für das Paket kann man einfach bestätigen.

• In die Paketbeschreibung kann man je nach Wunsch nichts oder z. B. die Kurzbeschreibung des Programms aus der Dokumentation übernehmen.

• Abschließend gibt checkinstall eine Übersicht über die Paketinformationen, die man editieren kann. Wichtig dabei sind korrekt gesetzter Paketname und Versionsnummer.

  • Der Paketname gewinnt insbesondere an Bedeutung für eine parallele Installation des selbst kompilierten Programms zu einem bereits in der Paketverwaltung^[1] bestehendem Paket. Dafür kann man den Paketnamen ändern, damit das bestehende Paket nicht überschrieben wird. Dadurch kann es aber auch zu Überschneidungen kommen, bei denen eine Fehlermeldung ausgegeben wird, dass eine Datei überschrieben werden soll, die auch in dem "ursprünglichen" Paket enthalten ist - die Installation bricht dann ab! Hier sollte man also zuvor an die --prefix-Einstellung beim configure-Skript denken.

  • Eine falsche Versionsnummer kann die Paketverwaltung^[1] dazu veranlassen, das "alte" Paket immer wieder zur Aktualisierung vorzuschlagen. Um das zu vermeiden, sollte man sich die Versionierung der Ubuntu-Pakete ansehen und die Versionsnummer dementsprechend setzen. Die vom Autor gesetzte Art der Versionierung eines Programms kann von der Ubuntu-Versionierung abweichen.

checkinstall wird nach dem Durchlauf ausgeben, ob die Installation erfolgreich war und wo das neu erstelle Paket abgelegt wurde.

Möchte man auf eine automatische Installation des neu erstellten Pakets verzichten, muss der folgende Befehl ausgeführt werden:

checkinstall --install=no 

Alternativ hilft auch der folgende Aufruf:

checkinstall 

Zwangsläufig wird checkinstall einen Fehler ausgeben, weil das Programm ohne Root-Rechte ein Paket nicht installieren kann. Das Paket wird aber trotzdem erstellt und kann anschließend manuell installiert^[1] werden.

install: cannot change permissions of `/usr/local/etc/mplayer': No such file or directory
make: *** [install-dirs] Fehler 1

dpkg-deb: Fehler: Parsen der Datei »/var/tmp/tmp.y9z26Ip5DO/package/DEBIAN/control«, nahe Zeile 7 Paket »mplayer«:
 Fehler in Versionszeichenkette »vaapi-1«: Versionsnummer beginnt nicht mit einer Ziffer
/var/tmp/tmp.y9z26Ip5DO/dpkgbuild.log (END)

user@computer:~/src/mplayer-vaapi-20110127/mplayer-vaapi$ sudo checkinstall --fstrans=no

checkinstall 1.6.2, Copyright 2009 Felipe Eduardo Sanchez Diaz Duran
  Diese Software wurde unter der GNU GPL veröffentlicht



*****************************************
**** Debian package creation selected ***
*****************************************

Das Paket wird entsprechend dieser Vorgaben erstellt:

0 -  Maintainer: [ root@Ideapad-S205 ]
1 -  Summary: [ mplayer VAAPI support ]
2 -  Name:    [ mplayer ]
3 -  Version: [ vaapi ]                                   <--- Hier der Fehler: Versionsnummer beginnt NICHT mit einer Zahl!
4 -  Release: [ 1 ]
5 -  License: [ GPL ]
6 -  Group:   [ checkinstall ]
7 -  Architecture: [ amd64 ]
8 -  Source location: [ mplayer-vaapi ]
9 -  Alternate source location: [  ]
10 - Requires: [  ]
11 - Provides: [ mplayer ]
12 - Conflicts: [  ]
13 - Replaces: [  ]

Geben Sie die betreffende Nummer ein, um die Vorgaben zu ändern: 

Installing with make install...

====================== Installations-Ergebnisse ==========================
install -d /usr/local/bin /usr/local/etc/mplayer /usr/local/lib
install -m 755 -s mencoder /usr/local/bin
install -d /usr/local/share/man/man1
install -m 644 DOCS/man/en/mplayer.1 /usr/local/share/man/man1/
cd /usr/local/share/man/man1 && ln -sf mplayer.1 mencoder.1
install -m 755 -s mplayer /usr/local/bin

====================== Installation erfolgreich ==========================

Copying documentation directory...
./
./AUTHORS
./Changelog
./README
./LICENSE

Kopiere Dateien in das temporäre Verzeichnis...OK

Stripping ELF binaries and libraries...OK

Komprimiere man-Seiten...OK

Erzeuge Datei-Liste...OK

Erstelle Debian-Paket... FAILED!                          <---- Hier das Resultat: .deb kann nicht erstellt werden.

*** Paket-Erstellung fehlgeschlagen

Möchten Sie die log-Datei sehen?  [y]: y

Lösche temporäre Dateien...OK

Schreibe Sicherungs-Paket...OK
OK

Lösche temporäres Verzeichnis...OK

Geben Sie die betreffende Nummer ein, um die Vorgaben zu ändern: 

sudo checkinstall --pkgversion VERSIONSNUMMER 

Deinstallieren¶

Das Deinstallieren eines Programms, das mit make install installiert wurde, ist prinzipiell nicht kompliziert. Man muss sich dazu wieder im Quelltextverzeichnis befinden und außerdem müssen die Entwickler im Makefile eine uninstall-Regel erstellt haben - was nicht immer der Fall ist. Der Befehl für das Deinstallieren ist:

sudo make uninstall 

Sollte man das für die Installation verwendete Quelltextverzeichnis bereits gelöscht haben, muss zuerst der Quelltext neu heruntergeladen, entpackt und anschließend noch einmal das configure-Skript für den selben Installationspfad, der mit --prefix=Pfad für die Installation gesetzt wurde, durchgelaufen sein.

Im Notfall hilft dann nur das eigene Interpretieren des Makefile oder das Forum, um zu erfahren, welche Dateien wo installiert wurden, um diese manuell mit Root-Rechten^[6] wieder entfernen zu können.

Quelltextverzeichnis säubern¶

Ein Grund, das Quelltextverzeichnis von allen kompilierten Programmteilen zu bereinigen, wäre z. B., wenn dem configure-Skript die falschen Optionen übergeben wurden. Oder man hat das Quelltextverzeichnis zwecks Weiterverarbeitung (z. B. Paketbau) nicht gelöscht und muss nach einem Distributionsupgrade alle Programme erneut kompilieren.

Das Bereinigen ist notwendig, weil make bereits kompilierte Programmteile erkennt und nicht neu kompilieren würde. Der Befehl, um ein Quelltextverzeichnis zu säubern, lautet:

make clean 

Um alle durch den configure- und make-Vorgang erstellten Dateien wieder zu entfernen, kann der Befehl

sudo make distclean 

verwendet werden.