Quelltextarchive¶

Quelltexte werden entweder als Archivdatei zum Herunterladen angeboten (häufig wird tar.gz verwendet) oder können direkt über eine Versionsverwaltung bezogen werden. Nach dem Herunterladen muss die Archivdatei im Homeverzeichnis entpackt werden. Entpackt man ein Archiv, 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 der gesamte entpackte Quelltext dort hinein verschoben wird.

Wer regelmäßig Programme kompiliert, nutzt gerne einen Ordner wie z. B. ~/Quelltexte/, innerhalb dessen die eigentlichen Quelltexte nach Programmnamen und Versionen getrennt liegen.

Dokumentation¶

Alle notwendigen Informationen für das Kompilieren und Installieren lassen sich in der Regel direkt im Quelltextverzeichnis oder aber auf der Entwicklerseite des jeweiligen Programms finden. Fast immer ist die Dokumentation auf Englisch, da dieses die Lingua franca der Computerwelt ist.

Im Quelltextverzeichnis befinden sich Textdateien wie README, INSTALL, BUILD o.ä., die weiterführende Informationen zu den Abhängigkeiten und Konfigurationsoptionen, sowie Installationsanweisungen enthalten.

In den meisten Installationsanleitungen, die nicht speziell für Ubuntu geschrieben sind, fehlt oft die Angabe des Befehls sudo ^[4], ist durch su ersetzt, oder die Befehlszeile ist stattdessen mit einem # für Root-Rechte gekennzeichnet. Bei Ubuntu muss für systemweit gültige Operationen stets sudo verwendet werden.

Abhängigkeiten für eine neue Paketversion¶

Möchte man kein neues Programm, sondern nur eine neuere Version eines bereits in den offiziellen Paketquellen vorhandenen Pakets kompilieren, dann lässt sich diese Hürde mit einem einfachen Befehl im Terminal 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 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 zum 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 den 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 in Punkt 2 automatisch als Abhängigkeit mitinstalliert.

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

Es kann vorkommen, dass bestimmte Abhängigkeiten einfach als Komplettpaket (Metapaket) aufgelistet sind, in den offiziellen Paketquellen aber auf mehrere einzelne Pakete verteilt sind.

Fehlende Pakete oder falsche Paketversion¶

Sollte ein Paket der Abhängigkeiten nicht in den offiziellen Paketquellen 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 rdepends), 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 Quelltexts.

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 sollte).

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.

./configure 

Bei Problemen bitte den Abschnitt Fehler beim Konfigurieren am Ende des Artikels beachten.

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 im separaten Artikel Programme kompilieren/Alternativen im Abschnitt "Abweichende Methoden" behandelt.

./autogen.sh 

./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. Bei Problemen bitte den Abschnitt Fehler beim Kompilieren am Ende des Artikels zu Rate ziehen.

Auf Computern mit mehreren CPU-Kernen kann man das Kompilieren oft erheblich beschleunigen, indem man make -jN statt make ausführt, wobei N für die Anzahl der CPU-Kerne steht. Allerdings kann es dabei zu Fehlern kommen, die bei einem einfachen make nicht auftreten. Beispielsweise kann der Festplattenzugriff massiv erhöht sein, so dass das Betriebssystem nicht mehr oder nur sehr langsam reagiert.

Installieren¶

Nachdem make fehlerfrei durchgelaufen ist, erfolgt normalerweise die Installation mit make install (siehe unten). Diese Art der Installation von Programmen wird für Debian-basierende Systeme mit dem Advanced Packaging Tool (APT) als Paketmanager nicht empfohlen, weil so die installierten Dateien nicht von der Paketverwaltung registriert werden und diese sogar stören können. Insbesondere ist eine (vollständige) Deinstallation des Programms häufig sehr schwierig.

Stattdessen soll an dieser Stelle drei Programme vorgestellt werden, die eine spätere Deinstallation deutlich erleichtern:

• checkinstall

• paco bzw. porg

Diese Werkzeuge werden im Folgenden kurz beschrieben. Ausführlichere Informationen sind den jeweiligen Einzelartikeln zu entnehmen. Den Königsweg zur Erstellung von Debian-Paketen (.deb) findet man unter Allgemeines Vorgehen sowie im Unterartikel Die Debian-Methode.

sudo checkinstall 

checkinstall 

Deinstallieren¶

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

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 helfen die bereits oben erwähnten Werkzeuge paco bzw. porg, um zu erfahren, welche Dateien wo installiert wurden.

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.

Terminal¶

Auch wenn das Terminal sehr ausführlich in einem 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 als Arbeitsverzeichnis gesetzt. Bevor man also einen Quelltext kompilieren kann, muss man erst mit cd in das Quelltextverzeichnis wechseln und von dort arbeiten.

Fehler beim Konfigurieren mit configure¶

In diesem Abschnitt werden einige häufig auftretende Fehler durch fehlende Abhängigkeiten beim Ausführen des configure-Skripts und mögliche Lösungen beschrieben.

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 ***

Fehler beim Kompilieren mit make¶

Auch beim Kompilieren können Fehler auftreten. Diese sind allerdings eher auf Probleme mit einer bestimmten Version oder auf das Verschulden der Autoren des jeweiligen Programms zurückzuführen. Das configure-Skript sollte im Vorfeld sicherstellen, dass alle Abhängigkeiten korrekt aufgelöst sind, was aber in seltenen Fällen nicht passiert sein kann.

So kann die Abhängigkeit von einer Bibliothek größer oder gleich einer bestimmten Version zwar aufgelöst sein, eine neuere Version dieser Bibliothek unglücklicherweise aber kleine Änderungen enthalten, die das Kompilieren empfindlich stören. Das wurde dann von den Autoren vielleicht einfach noch nicht bemerkt. Vielleicht haben die Autoren aber auch eine ganze Abhängigkeit vergessen.

Der erste Schritt ist wieder die Analyse der Ausgabe. Diesmal kommt es aber nicht auf die letzten Zeilen an, weil diese meist nur Folgefehler enthalten.

/usr/bin/ld: cannot find -lXtst

apt-file -l find libxtst | grep dev 

Intern¶

• GDB - Debugging, Hilfe zur Fehlersuche

• checkinstall

• paco - Alternative zu checkinstall

• porg - Nachfolger von paco (ab Ubuntu 16.10)

• Programme kompilieren/Alternativen

Extern¶

• Checkinstall – Pakete bauen ohne Mehraufwand - LinuxUser, 07/2006

• Auf zu den Quellen – Programme selber kompilieren - LinuxUser, 07/2005

• Sekundärsoftware aus Quellen - Ubuntu GNU/Linux, Marcus Fischer, Rheinwerk <openbook>