Programme kompilieren
Dieser Artikel wurde für die folgenden Ubuntu-Versionen getestet:
Dieser Artikel ist größtenteils für alle Ubuntu-Versionen gültig.
Artikel für fortgeschrittene Anwender
Dieser Artikel erfordert mehr Erfahrung im Umgang mit Linux und ist daher nur für fortgeschrittene Benutzer gedacht.
Zum Verständnis dieses Artikels sind folgende Seiten hilfreich:
Die Paketquellen von Ubuntu bieten einem Anwender eine große Vielzahl von Programmen. Manchmal kommt es aber vor, dass bestimmte Programme oder neuere Programmversionen nicht in diesen Paketquellen enthalten sind. Benötigt man ein solches Programm oder z.B. eine Funktion einer neueren Programmversion, dann bleibt einem oftmals nur der Weg über Fremdquellen wie einem PPA oder direkt über den Quelltext.
Dieser Artikel soll einen grundlegenden Überblick verschaffen, wie man den Quelltext für Linux-Programme unter Ubuntu kompiliert und installiert.
Experten-Info:
Die herkömmliche Erstellung von Debian-Paketen (.deb) wird in diesem Artikel nicht behandelt. Informationen dazu finden sich unter Paketbau.
Grundlegendes¶
Es gibt verschiedene Möglichkeiten unter Linux, einen Quelltext zu kompilieren, und noch mehr Möglichkeiten, das kompilierte Programm anschließend zu installieren. Abhängig ist das davon, um was für ein Programm es sich handelt, in welcher Programmiersprache es geschrieben wurde und welchen Compiler der Autor des Programms für sein Projekt bevorzugt. Für die eigentliche Installation ist dann die vom Betriebssystem verwendete Paketverwaltung[9] noch zusätzlich interessant.
Dieser Artikel befasst sich vorwiegend mit dem Kompilieren und Installieren von Programmen, die in der Programmiersprache C/C++ (unter Linux und anderen Betriebssystemen die am häufigsten verwendete Programmiersprache) geschrieben wurden, sowie einigen Hinweisen zu Programmen, die in einer Skriptsprache wie z.B. Python, Perl oder Ruby umgesetzt wurden. Die angesprochenen Methoden u.a. zur Installation beziehen sich dabei auf Debian-basierende Distributionen mit dem Advanced Packaging Tool (APT) als Paketmanager[9] - also auch Ubuntu. Als Compiler kommt dabei die sogenannte GNU_Compiler_Collection (GCC) zum Einsatz, mit dem als Quasi-Standard unter Linux u.a. auch Ubuntu erstellt wird.
Kurzfassung¶
Zunächst eine Kurzfassung des später im Detail beschriebenen Kompilationsprozesses. Sollte es zu Problemen kommen oder möchte man etwas mehr darüber wissen, was man hier tut, so sollte man auf jeden Fall die ausführlichen Beschreibungen der einzelnen Schritte oder am besten gleich den ganzen Artikel lesen. Wichtig ist, dass im Falle von Fehlermeldungen auf jeden Fall der Fehler beseitigt werden muss, bevor man zum nächsten Schritt übergeht.
Zunächst sind die für die nächsten Schritte nötigen Pakete build-essential und gegebenenfalls weitere Abhängigkeiten des zu kompilierenden Programmes zu installieren[1]. Soll das Programm anschließend systemweit installiert werden, wird noch das Paket checkinstall benötigt.
Dann wechselt man im Terminal[3] ins Quelltextverzeichnis[11] und führt folgende Befehle aus:
./configure | ausführliche Beschreibung |
make | ausführliche Beschreibung |
sudo checkinstall | ausführliche Beschreibung |
In vielen Fällen reicht dies zur Installation eines Programmes aus.
Vorbereitung¶
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.
Hinweis:
In den meisten Installationsanleitungen, die nicht für Ubuntu geschrieben sind, fehlt oft die Angabe des Befehls sudo, ist durch su ersetzt, oder die Befehlszeile ist statt dessen mit einem # für "root" gekennzeichnet. Bei Ubuntu muss für systemweit gültige Operationen stets sudo[6] verwendet werden.
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 auflösen¶
Jedes Programm hängt von Bibliotheken (so genannten "Libraries") und/oder anderen Programmen ab. Bei der Installation eines Paketes werden diese Abhängigkeiten automatisch von der Paketverwaltung[9] mitinstalliert. Für das Kompilieren eines Programms aus dem Quelltext müssen Abhängigkeiten allerdings manuell installiert werden. Dieser Vorgang stellt die erste Hürde dar, die man auf dem Weg zu einem selbst kompilierten Programm nehmen muss.
Die erste, grundlegende Abhängigkeit fehlt bereits, weil Ubuntu im Gegensatz zu anderen Linux-Distributionen von Haus aus keinen entsprechenden Compiler für C/C++ bei der Standardinstallation mitinstalliert. Die "GNU Compiler Collection" (GCC) sowie andere Werkzeuge sind in einem Metapaket enthalten, das über die Paketverwaltung nachinstalliert werden muss[1]:
build-essential
Befehl zum Installieren der Pakete:
sudo apt-get install build-essential
Oder mit apturl installieren, Link: apt://build-essential
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.
Befehl zum Installieren der Build-Abhängigkeiten:
sudo apt-get build-dep PAKETNAME
sudo aptitude build-depends PAKETNAME
Hinweis:
Falls sich für neuere Programmversionen die Abhängigkeiten geändert haben und um weitere Bibliotheken oder Programme erweitert worden sind, hilft ein vorheriger Blick in die Dokumentation.
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:
Programme für das Kompilieren und Installieren wie der Compiler oder das Build-System.
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.
Entwicklerdateien von Programmen für das Kompilieren. Entsprechende Pakete für diese Programme sind mit dem Suffix -dev gekennzeichnet.
Programme, auf denen das zu kompilierende Programm aufbaut und ohne die bestimmte Funktionen nicht ausführbar wären.
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.
Hinweis:
Es kann vorkommen, dass bestimmte Abhängigkeiten einfach als Komplettpaket aufgelistet sind, in den Paketquellen der Linux-Distribution aber auf mehrere Pakete verteilt sind. Falls das falsche Paket oder nicht alle Abhängigkeiten installiert sind, ist dies nicht weiter schlimm und wird noch an späterer Stelle auffallen.
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.
Hinweis:
Sollte man sich unsicher sein, ob man abschließend alle Abhängigkeiten korrekt auflösen konnte, dann stellt das meist kein Problem dar, weil fehlende Abhängigkeiten keine katastrophalen Folgen haben. Im folgenden Abschnitt zur Konfiguration im Vorfeld des eigentlichen Kompilierens wird darauf näher eingegangen.
Allgemeines Vorgehen¶
Diese Methode, deren ersten Schritte man als gängigen Standard unter Linux bezeichnen kann, beschreibt allgemeingültig das Kompilieren am Beispiel des GNU Build-System, auch bekannt als "autotools". Vorausgesetzt wird, dass der Anwender sich mit seinem Terminal[3] im Quelltextverzeichnis befindet.
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.
Hinweis:
Falls das configure-Skript nicht vorhanden ist, allerdings eine Datei autogen.sh, wird das Skript durch diese andere Datei erstellt:
./autogen.sh
Fehlermeldungen¶
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.
Beispiel 1:
checking for C compiler default output file name... configure: error: C compiler cannot create executables
Dieser Fehler sollte sehr frühzeitig auftauchen und weist darauf hin, dass kein passender Compiler gefunden werden konnte. Er bedeutet also, dass das Paket build-essential nicht oder nicht korrekt installiert wurde[1].
Beispiel 2:
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
⚓︎ Das Skript verweist in der Ausgabe sehr genau auf die fehlende Datei alsa.pc. Mit dieser Information kann man jetzt in der Ubuntu Paketsuche 🇬🇧 unter "Search contents of packages" direkt nach dieser Datei in einem Paket suchen, und wird als Ergebnis libasound2-dev erhalten. Dieses Paket muss jetzt nachinstalliert werden.
Anstelle der Ubuntu-Paketsuche kann man diese Suche auch über die Befehlszeile mit dem Werkzeug apt-file lösen.
Beispiel 3:
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.
Hier verweist die Ausgabe auf eine fehlende Bibliothek. Unter Berücksichtigung der Konventionen für die Benennung solcher Pakete lässt sich jetzt aus dem Namen der Bibliothek in der Ausgabe in Kombination mit Präfix und Suffix ein sinnvoller Suchbegriff generieren. In diesem Fall ist die Suche am effektivsten über den Begriff libgtk.
Die Suche kann entweder über einen Paketmanager-Frontend wie Synaptic durchgeführt werden, oder aber mit apt-file über Befehlszeile, bei dem die Suchergebnisse mit der Option -l auf Pakete beschränkt und mit grep noch weiter eingegrenzt werden können.
apt-file -l find libgtk | grep dev
Die Suchergebnisse enthalten u.a. das Paket libgtk-3-dev, welches hier am wahrscheinlichsten vermisst wird und nachinstalliert werden muss.
Beispiel 4:
checking for xmms-config... no checking for XMMS - version >= 1.2.4... no configure: WARNING: *** XMMS >= 1.2.4 not installed - please install first ***
Diesmal fehlt ein Programm, auf das aufgebaut wird. XMMS sollte sich als Paket recht leicht ausfindig machen und nachinstallieren lassen - allerdings nicht unter Ubuntu, da XMMS mit Ubuntu 8.04 Hardy Heron aus allen Paketquellen komplett entfernt wurde. Speziell in diesem Fall wäre also jedes weitere Vorgehen zum Scheitern verurteilt...
Weitere Optionen¶
Außer der Überprüfung der Abhängigkeiten können mit dem configure-Skript weitere systemspezifische Optionen an den Compiler übergeben werden. Selbst kompilierte Programme sollten grundsätzlich in den Ordner /usr/local installiert werden, was auch meist der Standardeinstellung des Skripts entspricht. Sollte das nicht so sein oder vom Anwender ein anderer Installationspfad gewünscht werden, kann man den mit der Option --prefix=Pfad übergeben. Folgender Befehl stellt sicher, dass die Dateien auf jeden Fall nach /usr/local installiert werden:
./configure --prefix=/usr/local
Weitere Optionen können in der Regel mit --enable-xyz ein- und mit --disable-xyz ausgeschaltet werden. Die vollständige Auflistung der Optionen erhält man entweder aus der Dokumentation oder mit dem Befehl:
./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.
Hinweis:
Auf Computern mit mehreren CPU-Kernen kann man das Kompilieren oft erheblich beschleunigen, indem man make -jN statt make ausführt, wobei N z.B. für die Anzahl der CPU-Kerne steht. Allerdings kann es dabei zu Fehlern kommen, die bei einem einfachen make nicht auftreten. Z.B. kann der Festplattenzugriff massiv erhöht sein, so dass das Betriebssystem nicht mehr oder nur sehr langsam reagiert.
Fehlermeldungen¶
Auch beim eigentlich Kompilieren können wieder Fehler auftreten. Diese sind allerdings eher auf Probleme mit einer Paketversion oder dem 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.
Beispiel 1:
Hier sollte man auf eine spezielle Zeile achten, die auf eine fehlende Datei mit der Endung .h hinweist. Hat man eine solche gefunden, ist das Problem schon so gut wie gelöst, und der größte Aufwand ist die Erstellung einer Fehlermeldung an den Programmautor wegen eines unvollständigen configure-Skriptes, das die fehlende Komponente nicht bemerkt hat.
Man muss nun herausbekommen, welches Paket die fehlende Datei enthält. Am Besten geht man so vor, wie oben bei Fehlermeldungen während des Konfigurierens in Beispiel 2 oder 3 erklärt, mit der Suche über die Ubuntu Paketsuche 🇬🇧 oder dem Wergzeug apt-file. Ist das Paket gefunden und installiert, kann make abermals ausgeführt werden und setzt dann glücklicherweise wieder da an, wo der Fehler aufgetreten ist. Bereits kompilierte Teile des Programms werden also in der Regel nicht neu kompiliert.
Beispiel 2:
/usr/bin/ld: cannot find -lXtst
Das Programm ld ist der "Linker", der beim Kompilieren alle Bibliotheken und Programmteile zusammenfügt. Mit -l... sind immer spezielle Bibliotheken (Libraries) gemeint. In diesem Fall geht man, wie oben beim Konfigurieren in Beispiel 2 oder 3 erklärt, vor:
apt-file -l find libxtst | grep dev
Als Ausgabe erhält man das Paket libxtst-dev, welches dann zusätzlich installiert werden muss.[1]
Installieren¶
Nachdem make fehlerfrei durchgelaufen ist, erfolgt die Installation hier mit checkinstall. Dazu muss das gleichnamige Paket installiert[1] werden:
checkinstall (universe)
Befehl zum Installieren der Pakete:
sudo apt-get install checkinstall
Oder mit apturl installieren, Link: apt://checkinstall
Hinweis:
Als alternative Installationsmöglichkeit, kann man sich die unter Ubuntu offizielle "Debian-Methode" anschauen.
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.
Hinweis:
Technisch betrachtet gilt die Verwendung von checkinstall als "quick & dirty", da nicht alle Möglichkeiten durch die herkömmliche Paketerstellung gegeben sind (beispielsweise Prüfsummen, Maintainer-Skripte oder Modifikationen beim Kompiliervorgang). Dadurch sind die mit checkinstall erstellten Pakete von niedrigerer Qualität, als die herkömmlich Erstellten. Zur Weitergabe sollte man deswegen unbedingt den herkömmlichen Weg vorziehen.
Hinweis:
Für das Kompilieren von Kernelmodulen (Treibern) ist checkinstall nicht geeignet. Hierbei muss entweder auf die Debian-Methode auf die Installation über make install aus der Standard-Methode zurückgegriffen werden. Ferner sei hier auch nochmal erwähnt, dass Kernel-Module bei Kernel-Updates, also der Installation eines neuen Kernels, immer neu kompiliert und installiert werden müssen. Hier bietet sich dkms an.
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.
Fehlermeldungen¶
checkinstall bricht Installation ab¶
Bricht checkinstall die Installation mit obskuren Fehlern ab, dann liegt das meist daran, dass es neue Dateien nicht anlegen kann. Das Problem liegt dann im "file translation code" von installwatch (einem Unterprogramm von checkinstall), das hierfür ein Art virtuelles Dateisystem bereitstellt, damit das Eigentliche nicht angerührt wird. Die Installationsroutine kann manchmal neu erstellte Dateien nicht finden und bricht deswegen ab. Dies kann dann beispielsweise so aussehen:
install: cannot change permissions of `/usr/local/etc/mplayer': No such file or directory make: *** [install-dirs] Fehler 1
Lösung¶
Mit der Option --fstrans=no beim Aufruf von checkinstall wird diese Funktion deaktiviert. Oft ist eine Installation auch erfolgreich, wenn zunächst make install ausgeführt wird, und danach ein checkinstall erfolgt.
Hinweis:
Problematisch ist in diesem Zusammenhang, dass mit Root-Rechten erstellte Dateien im eigenen Homeverzeichnis nicht vom eigentlichen Benutzer gelöscht werden können. Zum Löschen der mit sudo... selbst erstellten Pakete sind grundsätzlich Root-Rechte[6] erforderlich.
Erstellen von Paketname.deb schlägt fehl (Erstelle Debian-Paket... FAILED!)¶
Tritt beim Erstellen des Debian-Pakets obiger Fehler auf, so liegt dies wahrscheinlich daran, dass beim Aufruf von checkinstall und der damit einhergehenden Erstellung der Datei ./doc-pak eine ungütige Versionsnummer angegeben wurde.
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)
Beispiel mplayer (siehe Markierungen im Codeblock):
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
Lösung¶
Beim Aufruf von checkinstall und dieser Abfrage:
Geben Sie die betreffende Nummer ein, um die Vorgaben zu ändern:
die 3 wählen und eine Versionsnummer eingeben (am besten die Richtige), die mit einer Zahl beginnt. Dann sollte checkinstall problemlos durchlaufen.
Alternativ checkinstall direkt die Versionsnummer beim Aufruf übergeben:
sudo checkinstall --pkgversion VERSIONSNUMMER
Die Standard-Methode¶
Diese Methode unterscheidet sich lediglich beim Installieren von der Ubuntu-Methode. Die Abschnitte für die Schritte vorher können einfach übernommen werden:
Achtung!
Diese Art der Installation von Programmen wird so nicht für Debian-basierende Systeme empfohlen, weil so die installierten Dateien nicht von der Paketverwaltung[1] registriert werden und diese stören können. Auch ist eine (vollständige) Deinstallation des Programms häufig sehr schwierig.
Eine bessere Lösung findet man unter Allgemeines Vorgehen sowie im Unterartikel Alternativen, Die Debian-Methode.
Nachdem make fehlerfrei durchgelaufen ist, kann man das Programm jetzt mit folgendem Befehl im Verzeichnis, das mit ./configure --prefix=Pfad festgelegt wurde, installieren:
sudo make install
Bei manchen Programmen besteht die Möglichkeit, andere Installationsvarianten über make zu wählen bzw. auf make install kann noch ein weiterer Befehl folgen. Der Zusatz für install sieht von Programm zu Programm meist unterschiedlich aus und ist ggf. der Dokumentation zu entnehmen.
Als Beispiel die lokale Installation des Programms Xournal im Homeverzeichnis:[1]
./configure --prefix=$HOME make make install make home-desktop-install
Deinstallieren¶
Hinweis:
Dieser Schritt entfällt, wenn das Programm mit der Ubuntu- oder Debian-Methode installiert wurde.
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.
Alternativen¶
Weitere Methoden werden in Programme kompilieren/Alternativen beschrieben.
Links¶
GDB - Debugging, Hilfe zur Fehlersuche
Checkinstall - Pakete bauen ohne Mehraufwand 🇩🇪 - Artikel aus LinuxUser 07/2006
Programme selber kompilieren 🇩🇪 - Artikel aus LinuxUser 07/2005
Sekundärsoftware aus Quellen 🇩🇪 - aus "Ubuntu GNU/Linux" von Marcus Fischer, Rheinwerk <openbook>