Auch wenn moderne Paketmanager den allermeisten Software-Bedarf abdecken, gibt es Situationen, in denen man selbst kompilieren muss: Pakete fehlen im Repository, eine Compile-Option ist nötig, eine brandneue Version oder ein dringender Patch wird gebraucht. Dieser Artikel zeigt den klassischen ./configure && make && make install-Workflow sowie die modernen Alternativen CMake und Meson — und wie du dabei dem Paketmanager nicht ins Gehege kommst.
Wann kompilieren?
Die Standardregel ist klar: Pakete bevorzugen. Der Paketmanager kümmert sich um Abhängigkeiten, Updates und saubere Deinstallation. Selbst kompilieren lohnt sich nur in klar umrissenen Fällen.
| Situation | Warum kompilieren? |
|---|---|
| Paket fehlt im Repository | Nischen-Software, eigene Tools, sehr neue Projekte |
| Spezielle Compile-Optionen | CPU-Optimierungen (-march=native), Debug-Build, Feature-Flags |
| Neue Version dringend gebraucht | Distro liefert eine zu alte Version, Sicherheitspatch ist nötig |
| Eigener Patch | Du willst eine Änderung am Code testen oder einen Bug fixen |
| Embedded oder Cross-Compile | Zielsystem ist eine andere Architektur |
In allen anderen Fällen: Erst im Repo schauen, dann ein PPA oder ein offizielles .deb/.rpm versuchen, und nur als letzten Ausweg selbst bauen. Eigene Builds sind Wartungsaufwand — sie folgen keinem apt upgrade.
Build-Essentials installieren
Bevor irgendetwas kompiliert werden kann, brauchst du die grundlegende Toolchain: einen C/C++-Compiler (gcc oder clang), make, die Autotools, Header-Dateien der Standard-Bibliotheken. Jede Distribution stellt dafür ein Meta-Paket bereit.
sudo apt install build-essentialsudo dnf groupinstall "Development Tools"sudo pacman -S base-develDiese Pakete bringen gcc, g++, make, autoconf, automake, libtool, pkg-config und die wichtigsten Header. Für CMake-/Meson-Projekte brauchst du zusätzlich cmake bzw. meson und ninja.
sudo apt install cmake meson ninja-build pkg-configKlassisches Autotools-Trio
Das traditionelle GNU-Build-System besteht aus drei Schritten: ./configure, make, make install. Es ist seit den 1990ern Standard und läuft auf praktisch jedem Unix-artigen System.
| Schritt | Was passiert |
|---|---|
./configure | Prüft die Build-Umgebung, sucht Abhängigkeiten, erzeugt ein passendes Makefile |
make | Übersetzt den Quellcode in ausführbare Programme und Bibliotheken |
sudo make install | Kopiert das Ergebnis in die Zielverzeichnisse (Binaries, Manpages, Bibliotheken) |
Der entscheidende Parameter ist --prefix. Er legt fest, wohin installiert wird. Ohne explizites Prefix landet die Software meistens in /usr/local/, was OK ist — aber explizit ist besser.
tar xf programm-1.2.3.tar.gz
cd programm-1.2.3
./configure --prefix=/usr/local
make -j$(nproc)
sudo make install--prefix=/usr/local trennt deine selbst gebaute Software räumlich vom Paketmanager (der /usr/ verwaltet). make -j$(nproc) parallelisiert den Build über alle CPU-Kerne — das ist auf modernen Maschinen oft ein Faktor 4 bis 16 schneller.
Mit ./configure --help siehst du alle verfügbaren Optionen eines Projekts — typische Flags sind --enable-FEATURE, --disable-FEATURE, --with-LIBRARY und --without-LIBRARY.
CMake-Workflow
CMake hat sich in den letzten 15 Jahren als modernes Build-System durchgesetzt. Projekte wie LLVM, Qt, KDE oder OpenCV verwenden es. Statt eines fertigen Makefile erzeugt CMake je nach Generator Makefiles, Ninja-Build-Dateien oder IDE-Projekte.
cmake -B build -S . -DCMAKE_INSTALL_PREFIX=/usr/local
cmake --build build -j$(nproc)
sudo cmake --install buildWichtig: CMake nutzt einen Out-of-Source-Build. Alle erzeugten Dateien landen im build/-Ordner, der Quellbaum bleibt sauber. Zum Aufräumen reicht rm -rf build/.
| Flag | Bedeutung |
|---|---|
-B build | Build-Verzeichnis (wird angelegt, falls nicht vorhanden) |
-S . | Quellverzeichnis |
-DCMAKE_BUILD_TYPE=Release | Optimierter Build (Alternative: Debug, RelWithDebInfo) |
-DCMAKE_INSTALL_PREFIX=/usr/local | Installationspräfix |
-G Ninja | Generator wählen (Ninja ist schneller als make) |
Meson + Ninja
Meson ist das jüngste der drei Build-Systeme. Es setzt konsequent auf Ninja als Backend, ist deutlich schneller als CMake oder Autotools und hat eine lesbarere Syntax in den Build-Skripten. Viele GNOME-Komponenten und neuere Systemprojekte (z.B. systemd) verwenden Meson.
meson setup build --prefix=/usr/local
meson compile -C build
sudo meson install -C buildWie CMake nutzt Meson einen Out-of-Source-Build (build/-Ordner). Der setup-Schritt entspricht ./configure, compile ersetzt make, install ist wie gewohnt der Kopiervorgang. Build-Optionen werden mit -Doption=wert übergeben:
meson setup build --prefix=/usr/local --buildtype=release -Dgtk_doc=falseDependency-Hell lösen
Der häufigste Stolperstein beim Kompilieren: ./configure (oder cmake/meson) bricht mit einer Meldung wie „library X not found” oder „package XYZ is required” ab. Der Grund ist fast immer derselbe — es fehlt ein Development-Paket der entsprechenden Bibliothek.
Distributionen trennen Bibliotheken in zwei Pakete: das Runtime-Paket (mit der .so-Datei) und das Development-Paket (mit Headern und .pc-Dateien). Zum Kompilieren brauchst du beide — meistens reicht das -dev/-devel-Paket, das Runtime wird als Abhängigkeit mitgezogen.
| Distribution | Suffix | Beispiel |
|---|---|---|
| Debian / Ubuntu | -dev | sudo apt install libssl-dev |
| Fedora / RHEL | -devel | sudo dnf install openssl-devel |
| Arch / Manjaro | (keiner, alles im Hauptpaket) | sudo pacman -S openssl |
| openSUSE | -devel | sudo zypper install libopenssl-devel |
Wenn du nicht weißt, in welchem Paket eine bestimmte Datei liegt, helfen distributionsspezifische Tools weiter:
# Debian/Ubuntu
apt-file search libssl/ssl.h
# Fedora
dnf provides "*/ssl.h"
# Arch (mit pkgfile)
pkgfile ssl.hPraxis-Patterns
Die folgenden Befehle decken die häufigsten Build-Workflows ab. Alle Beispiele verwenden --prefix=/usr/local, was sich räumlich vom Paketmanager trennt und ein sauberes Setup ergibt.
Build-Essentials einrichten
sudo apt install build-essentialsudo dnf groupinstall "Development Tools"sudo pacman -S base-develEinmal pro System einrichten — danach steht die komplette GNU-Toolchain bereit.
Autotools-Standardbuild
./configure --prefix=/usr/local && make -j$(nproc) && sudo make installDie klassische Dreierkette als Einzeiler. -j$(nproc) parallelisiert den Build, --prefix=/usr/local schützt den Paketmanager.
CMake-Standardbuild
cmake -B build -DCMAKE_INSTALL_PREFIX=/usr/local && cmake --build build -j$(nproc) && sudo cmake --install buildOut-of-Source-Build im build/-Ordner. Zum Neuanfang reicht rm -rf build/ ohne den Quellbaum zu berühren.
Meson-Standardbuild
meson setup build --prefix=/usr/local && meson compile -C build && sudo meson install -C buildDer schnellste der drei Workflows — Meson erzeugt Ninja-Build-Dateien, die deutlich zügiger laufen als klassische Makefiles.
Saubere Deinstallation
sudo make uninstallFunktioniert oft, ist aber nicht garantiert. Voraussetzung ist, dass der Build-Verzeichnisbaum mit den gleichen Optionen noch vorhanden ist. Sicherer sind stow oder checkinstall.
checkinstall — alte Schule, immer noch nützlich
./configure --prefix=/usr/local
make -j$(nproc)
sudo checkinstallcheckinstall ersetzt den make install-Schritt. Es packt das Ergebnis in ein .deb (oder .rpm/.tgz) und installiert es über den Paketmanager. Damit lässt sich die Software später sauber per apt remove entfernen.
stow als Best Practice
GNU Stow ist die eleganteste Lösung für selbst kompilierte Software. Die Idee: Jede Software wird in ein eigenes Verzeichnis unterhalb von /usr/local/stow/ installiert. Stow legt dann Symlinks in /usr/local/bin/, /usr/local/lib/ etc. an. Zum Deinstallieren reicht ein Kommando — alle Symlinks verschwinden, das Programm ist sauber weg.
./configure --prefix=/usr/local/stow/programm-1.2.3
make -j$(nproc)
sudo make installcd /usr/local/stow
sudo stow programm-1.2.3Das Programm ist jetzt unter /usr/local/bin/programm verfügbar — über einen Symlink, der ins Stow-Verzeichnis zeigt. Zum Entfernen:
cd /usr/local/stow
sudo stow -D programm-1.2.3
sudo rm -rf programm-1.2.3Vorteile: Mehrere Versionen parallel installierbar, Wechsel per stow/stow -D, perfekte Trennung zwischen Programmen, kein Suchen nach „wohin hat make install was kopiert?“.
Stolperfallen
make install ohne Prefix kann den Paketmanager kaputt machen
Ohne explizites --prefix landet die Software meistens in /usr/local/ — das ist OK und vom FHS dafür vorgesehen. Schlimm wird es, wenn ein Projekt-Default /usr/ ist (oder du es manuell so setzt): Dort verwaltet der Paketmanager die Dateien. Ein selbst gebautes Programm in /usr/bin/ kann ein vorhandenes Paket-Binary überschreiben — und beim nächsten Distributions-Upgrade gibt es Konflikte oder kaputte Pakete. Regel: NIEMALS in /usr/ installieren. Verwende /usr/local/ oder besser /opt/programm/ für komplett gekapselte Installationen.
make -j ohne Argument startet zu viele Jobs
Das Flag -j ohne Zahl bedeutet unbegrenzt parallel — make startet so viele Compile-Jobs, wie Targets gleichzeitig anstehen. Bei großen Projekten wie Chromium oder LLVM kann das den RAM sprengen und das System einfrieren. Verwende immer -j$(nproc), um die Job-Anzahl an die Anzahl der CPU-Kerne zu binden. Auf Maschinen mit wenig RAM ist sogar -j$(($(nproc)/2)) sinnvoll, weil C++-Compiler-Jobs leicht 2 GB RAM pro Job belegen können.
Source-Tarball-Signaturen prüfen
Wer Code aus dem Netz herunterlädt und mit Root-Rechten installiert, sollte vorher die Authentizität prüfen. Seriöse Projekte signieren ihre Releases mit PGP oder veröffentlichen mindestens SHA-256-Summen auf einer separaten Seite. Mit gpg --verify programm-1.2.3.tar.gz.sig oder sha256sum -c programm-1.2.3.tar.gz.sha256 kannst du den Tarball verifizieren. Ein manipuliertes ./configure-Skript wird mit deinen Rechten ausgeführt — das ist ein realer Angriffsvektor (siehe xz-Backdoor von 2024).
make uninstall ist nicht garantiert vorhanden
Das Autotools-System bietet zwar einen uninstall-Target, aber nicht jedes Projekt implementiert ihn korrekt — und CMake/Meson generieren ihn standardmäßig gar nicht. Hast du das Build-Verzeichnis gelöscht oder die Quellen weggeworfen, fehlt dir die Information, welche Dateien wohin kopiert wurden. Verwende daher von Anfang an stow (Symlinks im eigenen Verzeichnis) oder checkinstall (erzeugt ein .deb/.rpm). Beide Ansätze machen die Deinstallation trivial.
Glibc-Versions-Konflikte bei älteren Distros
Wenn du auf einer alten Distribution (Debian Stable, RHEL 7) ein Projekt baust, das eine sehr neue Glibc oder sehr neue C++-Features braucht, kann der Build mit kryptischen Linker-Fehlern abbrechen. Glibc ist abwärtskompatibel, aber nicht aufwärts: Ein Binary, das gegen Glibc 2.38 gelinkt wurde, läuft nicht auf einem System mit Glibc 2.31. Lösungen: Toolchain aktualisieren (z.B. via Devtoolset auf RHEL), eine neuere Distro verwenden, oder das Projekt auf einer kompatiblen Glibc-Version pinnen.
configure --help nicht ignorieren
Viele Build-Probleme entstehen, weil Standard-Optionen nicht passen. ./configure --help zeigt alle verfügbaren Flags eines Projekts — typischerweise --enable-FEATURE, --disable-FEATURE, --with-LIBRARY=PATH. Ein Build kann monatelang als „kaputt” gelten, obwohl ein passendes --without-doc oder --with-openssl=/usr/local ihn sofort durchlaufen ließe. Bei CMake hilft analog cmake -LH ., bei Meson meson configure build.
Längere Pause zwischen configure und make? Lieber neu starten
Hast du nach ./configure System-Pakete installiert oder Compiler aktualisiert, sind die im Build-Verzeichnis gecachten Pfade und Versionen veraltet. make baut dann gegen die alten Annahmen. Ein make clean && ./configure ... (oder bei CMake rm -rf build && cmake -B build ...) räumt zuverlässig auf. Bei mysteriösen Linker-Fehlern nach Systemänderungen ist ein sauberer Neuanfang fast immer der richtige Reflex.
Cross-Compile für ARM ist ein eigenes Thema
Wenn du auf einem x86-Rechner ein Binary für einen Raspberry Pi oder ein Embedded-Board bauen willst, reicht der Standardablauf nicht. Du brauchst eine Cross-Toolchain (gcc-aarch64-linux-gnu), passende Sysroot-Pfade und passende --host-Flags für ./configure bzw. -DCMAKE_TOOLCHAIN_FILE=... für CMake. Das ist mächtig, aber mit eigenen Stolperfallen — typischerweise lohnt sich für Hobbyprojekte, einfach auf dem Zielgerät selbst zu kompilieren, auch wenn es länger dauert.
Weiterführende Ressourcen
Externe Quellen
- GNU Autoconf Manual — Offizielle Dokumentation zu autoconf und dem
configure-Skript-System - GNU Automake Manual — Automake-Dokumentation, ergänzt autoconf
- CMake Documentation — Vollständige CMake-Referenz und Tutorials
- Meson Build System — Offizielle Meson-Dokumentation mit Tutorial
- GNU Stow — Manual für Symlink-basiertes Paket-Management
- Linux From Scratch (LFS) — Das Standardwerk fürs Selber-Bauen eines kompletten Linux-Systems
Verwandte Artikel
- apt – Pakete unter Debian/Ubuntu — Der bevorzugte Weg zur Installation
- dnf – Pakete unter Fedora/RHEL — Der RPM-basierte Paketmanager
- pacman – Pakete unter Arch — Rolling-Release-Paketverwaltung
- Paketquellen verstehen — Repositories und Vertrauensketten
- find – Dateien finden — Nützlich beim Aufspüren installierter Build-Artefakte