Liegt die neue Version einer Software nur im Quelltext vor, stehen Sie vor der Alternative: aufs Paket warten oder selbst kompilieren. Wir helfen beim Eigenbau.

Programmierer entwickeln Software in der Regel in einer für den Menschen im Klartext lesbaren Programmiersprache wie C oder C++. Die CPU des Computers verarbeitet diesen Quellcode allerdings erst nach dem Übersetzen (Kompilieren) in Maschinencode (Assembler). Dieser Binärcode ist in der Regel nur unter einer bestimmten Umgebung lauffähig.

Daher veröffentlichen die Entwickler meist nur den Quellcode für ihr Programm und überlassen das Kompilieren den Maintainern der Distributionen. Wenn es jedoch für ein Programm gar kein oder kein aktuelles Paket gibt, lohnt es sich, den Quellcode selbst zu kompilieren, statt auf vorgefertigte Pakete zu warten (siehe Kasten “Werkzeuge”).

Mit etwas Glück ist das mit der Eingabe von ./configure; make; sudo make install erledigt (vergleiche Kasten “Grundlagen”). Doch oft genug bricht das Übersetzen vorzeitig ab. Eventuell liegt im Quellcode-Ordner gar kein Configure-Skript, weil ein anderes Build-System als GNU Autotools [1] zum Einsatz kommt. Dann braucht es etwas mehr als den Dreisatz, um zum Ziel zu gelangen.

./configure --prefix=/usr/local
make -j 9
sudo make install

mkdir build
cd build
cmake ../
make -j9
sudo make install

Fleißige Helfer

Hilfreich ist etwas Wissen darüber, was eigentlich passiert, wenn beim Kompilieren seitenweise Text über die Konsole scrollt (Abbildung 1). Dabei gehen wir zunächst von einem C/C++-Programm aus, das das verbreitetste Build-System GNU-Autotools nutzt.

Abbildung 1: Hunderte solcher Compiler-Aufrufe wie der rot eingerahmte sind nötig, um ein durchschnittliches Programm zu kompilieren. Es leuchtet ein, dass Entwickler diese nicht per Hand schreiben, sondern mithilfe eines Build-Systems erzeugen.

Bei den meisten der vorbeirauschenden Zeilen handelt es sich um Aufrufe des Compilers: Der praktischen Handhabbarkeit wegen bestehen typische Programme aus Hunderten oder Tausenden Quellcodedateien, die alle jeweils einen Aufruf des Compilers erfordern. Es wäre theoretisch möglich, diese per Hand in ein Bash-Skript zu packen.

Viel einfacher geht dies jedoch mit dem als Autotools bekannten GNU Build System [1]: Es erzeugt in einem mehrstufigen Prozess weitgehend automatisch diese Aufrufe für alle erforderlichen Dateien. Deshalb setzen praktisch alle heutigen Programme beim Kompilieren auf die Autotools oder vergleichbare Build-Systeme (Tabelle “Verbreitete Build-Systeme”).

Das eigentliche Steuern beim Kompilieren übernimmt dabei GNU Make [4], ein speziell darauf zugeschnittener Makro-Prozessor. Die Autotools erstellen die Makefile genannten Steuerdateien. Diese weisen Make an, die Quellcode-Dateien mit den Endungen .c (C-Dateien) oder .cpp (C++) in sogenannte Objektdateien (Endung .o ) zu übersetzen. Am Schluss folgt das Zusammenfügen der zahlreichen Objektdateien zu einer großen ausführbaren Datei wie gimp oder inkscape.

Im Quellcode liegt jedoch zunächst nur mit Makefile.in die Vorstufe des Makefiles, die das Configure-Skript an die konkrete Systemumgebung anpasst. Dieses Skript entsteht ebenfalls automatisiert. Das erklärt seine Größe und die Anzahl der mehr oder weniger nützlichen Tests, die bei jedem Aufruf in einer mit checking beginnenden Zeile auf der Konsole auflaufen.

Configure prüft, ob die vom zu kompilierenden Programm gebrauchten Bibliotheken installiert sind – jedenfalls die, an die die Entwickler gedacht haben. Optimalerweise startet das zeitraubende Übersetzen aus dem Quellcode erst, wenn alle Voraussetzungen dafür stimmen.

Unterschiedliche Versionen der im System installierten Bibliotheken sind der Grund, warum viele Programmpakete nur mit speziellen Versionen einer Distribution zusammenarbeiten: Sie sind technisch bedingt an eine bestimmte Variante aller genutzten Bibliotheken gebunden. Im Vergleich dazu bietet das Kompilieren mehr Flexibilität: Nur inkompatible Änderungen im Funktionsumfang einer Bibliothek, den das Programm wirklich nutzt, stellen hier ein Problem dar.

Beim Kompilieren prüft der Compiler, ob die Bibliotheken alle genutzten Funktionsaufrufe genauso anbieten, wie das Programm es erwartet. Abgesehen von tieferliegenden funktionalen Bugs bietet das Kompilieren also eine Art Garantie, dass die Software mit der Systemumgebung kompatibel ist.

Problemfälle

Nach diesen Hintergrundinformationen ist es Zeit den Compiler anzuwerfen: Als erstes Beispiel dient der Gnome-CD-Ripper Grip [5]. Nach dem Entpacken des Quellcodes [3] lieferte das aus dem entpackten Unterordner heraus aufgerufene ./configure im Testlauf eine Fehlermeldung (Listing 3).

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
[...]
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for GNOME... no
configure: error: Package requirements (libgnomeui-2.0 >= 2.2.0) were not met:
Package 'libgnomeui-2.0', required by 'virtual:world', not found

Offenbar fehlt also das benötigte Paket libgnomeui-2.0 beziehungsweise das zugehörige Devel-Paket: Zum Kompilieren braucht es stets diese Entwickler-Variante, die Grundversion kommt ohnehin als Abhängigkeit hinzu. Bei Arch-Linux gibt es keine Devel-Pakete, die dort enthaltenen Dateien (Header) sind hier ins Grundpaket integriert.

Das passende Paket zu finden, fällt in diesem Fall leicht: Der Paketname lautet libgnomeui-dev für Debian und Ubuntu, beziehungsweise libgnomeui-devel für OpenSuse und Fedora. Für Arch-Linux gibt es das alte Gnome-2-Paket nicht mehr in den Standard-Repositories, Sie kompilieren es, wie Grip selbst, über das AUR-Paket libgnomeui.

Manchmal ist es nicht so einfach das passende Paket zu finden, denn die Ausgabe von Configure nimmt keine Rücksicht auf die Namenskonventionen der Distributionen. Meist hilft es, Vorsilben wie lib oder angehängte Ziffern bei der Suche wegzulassen. Der Kasten “Paketquellen” hilft hier ebenfalls weiter.

Abbildung 2: Die Spec-Dateien auf dem Build-Service von OpenSuse zeigen exemplarisch die zum Kompilieren nötigen Abhängigkeiten und die Aufrufe auf der Kommandozeile, die zum Erfolg führen – jedenfalls unter OpenSuse 15. Für OpenSuse 42.3 ist der Paketbau fehlgeschlagen (rechts oben).

Abbildung 3: Auf Launchpad interessieren die DSC-Dateien, die zwar nicht die für das Kompilieren nötigen Befehle offenbaren, aber immerhin die unter Ubuntu für erfolgreiches Kompilieren zu installierenden Pakete.

Durch die Lappen

Die Abhängigkeiten, die Configure prüft, müssen die Entwickler per Hand benennen, der Check ist daher in der Praxis nicht immer vollständig: In so einem Fall läuft zwar Configure durch, was Sie an Zeilen wie configure: creating ./config.status am Schluss der Ausgabe erkennen. Beim folgenden Kompilieren mit Make fehlen dann aber benötigte Header, um dem Compiler das Verlinken gegen eine Bibliothek zu ermöglichen. Listing 4 demonstriert diesen Fehler für ein C-Programm.

gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I/usr/include -DGNOME_ICONDIR=\""/usr/share/pixmaps"\" -DG_LOG_DOMAIN=\"grip\" -DGNOMELOCALEDIR=\""/usr/share/locale"\" -I../intl -I../intl -DPREFIX=\""/usr"\" -DSYSCONFDIR=\""/etc"\" -DDATADIR=\""/usr/share"\" -DLIBDIR=\""/usr/lib"\"
[...]
main.c:24:10: schwerwiegender Fehler: gnome.h: Datei oder Verzeichnis nicht gefunden
#include <gnome.h>
^~~~~~~~~

C++ kennt zum Einbinden von Header-Dateien eine alternative Syntax, bei der die Endung .h nicht mehr auftaucht (Listing 5).

[  3%] Built target k8json_autogen
/build/clementine/src/Clementine/gst/moodbar/gstfastspectrum.cpp:25:10: schwerwiegender Fehler: QMutex: Datei oder Verzeichnis nicht gefunden
#include <QMutex>
^~~~~~~~

Dennoch fehlt hier eine Header-Datei, nämlich qmutex.h. Zum Glück ist dieses häufige Problem leicht zu lösen, zumindest, wenn für Ihre Distribution ein Paket für die von Configure übersehene Bibliothek existiert. Sie brauchen dazu lediglich im Paketmanager nach dem Paket zu suchen, die die fehlende Header-Datei enthält.

Unter Arch Linux geht dies am einfachsten mit dem Tool Pkgfile. Das entsprechende Werkzeug in der Debian-Welt heißt Apt-file. Fedora-Anwender finden das gesuchte Paket mit dnf provides '*qmutex.h'. Unter OpenSuse hilft ein zgrep -i "qmutex.h" ARCHIVES.gz" über die in den offiziellen Repositories liegende Indexdatei [10].

Neues System

Finden Sie im Quellcode kein Configure-Skript, hat dies unter Umständen mehrere Gründe: Eventuell baut erst der Aufruf von ./autogen.sh das Skript individuell. Es kommt aber oft vor, dass die Software ein anderes Build-System nutzt (vergleiche Tabelle “Verbreitete Build-Systeme”).

Das nach den vorgestellten Autotools verbreitetste ist Cmake [11]. Sie erkennen seinen Einsatz daran, dass statt des Configure-Skripts die Datei CMakeLists.txt im Wurzelverzeichnis des Quellcodes liegt (Abbildung 4).

Abbildung 4: Nutzt eine Software CMake als Build-System, dann liegt im Quellcode statt configure eine Datei CMakeLists.txt.

Cmake erzeugt ebenfalls Makefiles. Das eigentliche Kompilieren startet also wieder der vertraute Aufruf make. Zuvor starten Sie allerdings mit cmnake das Configure-Äquivalent. Es ist üblich, vorher im Quelltextordner einen Unterordner zu erstellen, etwa mit dem Namen build. Dies erlaubt mehrere Anläufe beim Kompilieren, die sich nicht gegenseitig überschreiben.

Wechseln Sie also zuerst in den build-Ordner, und geben Sie cmake ../ ein. Wie bei configure ist es hier möglich, dass Fehlermeldungen wegen fehlender Abhängigkeiten auftreten (Listing 6).

CMake Error at /usr/share/cmake-3.12/Modules/FindBoost.cmake:2048 (message):
Unable to find the requested Boost libraries.
Unable to find the Boost header files. Please set BOOST_ROOT to the root
directory containing Boost or BOOST_INCLUDEDIR to the directory containing
Boost's headers.
Call Stack (most recent call first):
CMakeLists.txt:52 (find_package)

Allerdings steht diese Meldung nicht am Schluss der Ausgabe, sondern mitten im Buchstabensalat. Am Ende findet sich nur die generische Warnung — Configuring incomplete, errors occurred! im auf dem Terminal ausgegebenen Text. Das liegt daran, dass Cmake nicht beim ersten Fehler anhält, dafür aber gleich beim ersten Durchlauf alle fehlenden Abhängigkeiten meldet.

Hier ist eine der grundlegenden Techniken beim Kompilieren gefragt, nämlich zunächst nach dem ersten Auftreten des Worts “error” oder “Fehler” zu suchen. Die meisten Konsolenprogramme bringen dafür eine Suchfunktion mit. Im Beispiel führt dies schnell zur Meldung Unable to find the requested Boost libraries (Listing 6, Zeile 2).

Herauszufinden, welches Paket nun die fehlenden Dateien enthält, erweist sich in der Praxis nun als etwas kniffelig: Besonders OpenSuse zerlegt Bibliotheken oft in viele kleine Einzelpakete (Abbildung 5).

Abbildung 5: Die Kreativität der Distributionen beim Benennen und Aufsplitten von Paketen kennt leider manchmal kaum Grenzen – wie hier unter OpenSuse für “boost”.

Als am nützlichsten zeigt sich dort der Aufruf von zypper search boost | grep devel: Unter den 34 Paketen, die der Aufruf liefert, wies die Beschreibung von libboost_headers1_66_0-devel als “Development headers for Boost” ohne Zusatz das Paket als hier benötigtes Grundpaket aus. Im Zweifelsfall gehen Sie das Problem pragmatisch an und installieren einfach alle im Paketmanager gefunden Erweiterungen der Bibliothek.

Die anderen Paketmanager verfügen ebenfalls über eine Suchfunktion nach dem Namen der Pakete. Außer bei Arch bietet sich bei diesen der Filter | grep dev oder | grep devel als sinnvolle Ergänzung an. Existiert für eine Distribution jedoch ein Paket für das zu übersetzende Programm, und sei es für eine ältere Version, so ist ein Blick in seine Paketquellen zu empfehlen (Kasten “Paketquellen”).

Immer spannend

In den bisherigen Beispielen scheiterte das Kompilieren an fehlenden Abhängigkeiten, ob nun bereits von Configure gemeldet oder weil der Compiler später beim Übersetzen an einer fehlenden Header-Datei scheiterte. Doch die Zahl der Fehlerquellen beim Kompilieren ist Legion, selbst nach Jahren Erfahrung laufen Ihnen vermutlich noch neue Typen über den Weg.

Zum Glück offerieren hier die Suchmaschinen im Netz tatkräftige Hilfe: Isolieren Sie mit einer Suche nach “error” oder “Fehler” im Text die Nachricht zur Ursache und starten danach einer Recherche, stehen die Chancen gut, dass andere Nutzer bereits eine Lösung gefunden haben.

Zeigt der Build-Vorgang die Fehlermeldungen auf Deutsch, dann sollten Sie auf der Konsole export LC_ALL=C eingeben und den gescheiterten Vorgang erneut starten: Deutsche Meldungen finden sich im Internet nur selten.

Als Beispiel für so einen Fall nutzen wir KeePassXC [12]. Beim Kompilieren des Programms tritt nach einem Update auf Version 5.11 der Bibliothek Qt5 ein Fehler auf (Listing 7).

[ 50%] Building CXX object src/CMakeFiles/keepassx_core.dir/gui/entry/EditEntryWidget.cpp.o
/home/cornelius/abs/keepassxc/src/keepassxc-2.3.3/src/gui/entry/EditEntryWidget.cpp: In constructor 'EditEntryWidget::EditEntryWidget(QWidget*)':
/home/cornelius/abs/keepassxc/src/keepassxc-2.3.3/src/gui/entry/EditEntryWidget.cpp:81:59: error: invalid use of incomplete type 'class QButtonGroup'
     , m_autoTypeDefaultSequenceGroup(new QButtonGroup(this))

Wer sich ein wenig mit dem grafischen Toolkit Qt auskennt, findet schnell den Schuldigen. Doch zum Lösen des Problems ist das gar nicht nötig: Selbst ohne dieses Wissen führt eine Suche nach “invalid use of incomplete type ‘class QButtonGroup'” zu einem Eintrag im Arch-Linux-Forum [13].

Dort sind Links zum Arch-Bugtracker [14] sowie zum Bugtracker von KeePassXC selbst auf Github genannt [15]. Mit beiden Quellen lösen Sie den Fehler – und zwar nicht nur als Arch-Linux-Anwender.

Der Arch-Linux-Bugtracker enthält als Attachment eine sogenannte Patch-Datei. Patches (englisch “Flicken”) sind eine Möglichkeit, beliebig viele Änderungen an einem Quelltext in eine Datei zu verpacken.

Zum Anwenden genügt es vom Quelltextordner heraus patch -p1 -i keepassxc.patch aufzurufen. Geht alles glatt, antwortet Patch mit der Meldung patching file src/gui/entry/EditEntryWidget.cpp. Gegebenenfalls installieren Sie vorher noch das Paket patch.

Auf dem Github-Bugtracker zu KeePassXC findet sich die gleiche Lösung, wenn gleich etwas versteckt (Abbildung 6). Ein Kommentar erwähnt, dass die Entwickler den Fehler nach Erscheinen von Programmversion 2.3.3 gefixt haben. Er verweist auf Commit 3bbc6ac und darauf, dass dieser sich als Patch auf Version 2.3.3 anwenden lasse. Doch wie gelangen Sie hier zu dem Patch?

Abbildung 6: Hier ist auf der Github-Seite von KeePassXC eine Lösung in Form eines Commits im Versionskontrollsystem angekündigt, die Sie in den Build-Vorgang zu Hause einbringen.

Die Commit-Nummer liegt bei dem auf Github genutzten Versionskontrollsystem Git [16] in hexadezimaler Form vor. Ein Klick darauf zeigt den Inhalt der Commits in tabellarischer Form. Für einen auf dem lokalen Rechner anwendbaren Patch brauchen Sie nur der nun verhandenen URL am Ende .patch hinzuzufügen.

Zu guter Letzt

Lief das Kompilieren endlich ohne Fehlermeldung durch, dann dürfen Sie den übersetzten Binärcode endlich installieren. Dazu dient bei den verbreitetsten Build-Systemen Autotools und CMake der Aufruf sudo make install. Die Gefahr, dass dieser letzte Schritt fehlschlägt, ist zwar gering. Doch da er ungefragt existierende Dateien überschreibt, besteht das Risiko, dass dabei das System oder andere Programme Schaden nehmen.

Um diese Gefahr zu minimieren, sollten Sie zwei Dinge beachten: Setzen Sie wie im Kasten “Grundlagen” beschrieben stets explizit das Präfix /usr/local. Moderne Linux-Systeme nutzen Verzeichnisse unterhalb dieses Ordners nicht. Daher zieht das make install höchstens andere, von Ihnen selbstkompilierte Programme in Mitleidenschaft.

Sinnvoll ist außerdem der Einsatz des Tools Porg [17]: sudo porg -lp Name-Version "make install" zeichnet alle Schreibvorgänge auf, die der als Parameter in Anführungszeichen übergebene Aufruf vornimmt. porg -f Name-Version oder das mitgelieferte grafische Programm Grop listet die geschriebenen Dateien dann auf.

So wissen Sie, was auf dem System beim Aufruf von make install passiert ist und sehen im Zweifelsfall, welches andere Programm Sie dabei unter Umständen beschädigen und daher neu installieren sollten. Last but not least deinstalliert Porg Programme, deren Build-System den Aufruf make uninstall nicht unterstützt.

Ubuntu bringt ein Paket für Porg mit, OpenSuse jedoch nicht. Porg bietet sich hier also als guter Einstieg in das Kompilieren an. Sobald Sie das Programm mit sudo make install installiert haben, schicken Sie noch den Aufruf sudo porg -lp porg-0.10 "make install" hinterher, um das Programm gleich in seiner eigenen Datenbank zu registrieren (Abbildung 7)

Abbildung 7: Porg kapselt den Aufruf von make install und protokolliert installierte Dateien. Hier ist das mitgelieferte Frontend Grop zu sehen.

Fazit

Dank Ubuntus “Personal Package Archives” (kurz PPAs) oder dem Build Service von OpenSuse kommt es nur noch selten vor, dass Anwender zwingend ein Programm, das es bislang noch gar nicht oder nicht in der neuesten Version in den Paketquellen gibt, von Hand aus dem Quellcode bauen. Oft genug finden sich ohne große Suche eine Paketquelle oder entsprechende Einzelpakete im Netz.

Allzu unbedarft sollten Sie solch fremden Paketen allerdings nicht trauen. Über die Paketverwaltung ins System eingespielt, könnten Sie beliebige Daten auf dem Rechner manipulieren und Malware einspielen. Achten Sie daher darauf, dass die Pakete am besten direkt vom Entwickler der gewünschten Software stammen oder bauen Sie das Programm eben aus dem Quellcode selbst.