Linux/Programme kompilieren

Beschreibung

Die offiziellen Paketquellen von Ubuntu bieten einem Nutzer eine große Vielzahl an Programmen

Manchmal kommt es aber vor, dass bestimmte Programme oder Programmversionen nicht in diesen Paketquellen enthalten sind

Benötigt man ein solches Programm oder eine bestimmte Funktion einer neueren Programmversion, dann bleibt einem oftmals nur der Weg direkt über den Quelltext

Die Erstellung von Debian-Paketen (.deb) wird hier nur am Rand 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 [wikipedia:Compiler]] der Programmautor bevorzugt
Für die eigentliche Installation ist dann die vom Betriebssystem verwendete Paketverwaltung noch zusätzlich interessant
Bei Debian und Ubuntu ist dies APT

Dieser Artikel befasst sich vorwiegend mit dem Kompilieren und Installieren von Programmen, die in der Programmiersprache [wikipedia:C]]/[wikipedia:C++]] geschrieben wurden (unter Linux und anderen Betriebssystemen die am häufigsten verwendete Programmiersprache)

Dabei kommt die sogenannte "GNU Compiler Collection" (GCC) zum Einsatz, der Quasi-Standard unter Linux
Sollte der Quellcode dagegen für die Interpretersprachen wie z
B. Python, Perl oder Ruby geschrieben worden sein, sei auf die genannten Artikel verwiesen

Kurzfassung

Zunächst eine Kurzfassung des später im Detail beschriebenen Kompilationsprozesses

Wichtig ist, dass im Falle von Fehlermeldungen das Problem zuerst beseitigt werden muss, bevor man zum nächsten Schritt übergeht

Für die nächsten Schritte ist folgendes Paket zu installieren [1]:

build-essential

Gegebenenfalls sind zusätzlich weitere [#Abhaengigkeiten-aufloesen Abhängigkeiten] des zu kompilierenden Programms zu installieren

Näheres dazu weiter unten

Nach dem Herunterladen einer Archivdatei mit dem Quelltext und dem Entpacken des Archivs [2] wechselt man im Terminal ins Quelltextverzeichnis und führt folgende Befehle aus [3]:

"./configure"

#Konfigurieren ausführliche Beschreibung

make

#Kompilieren ausführliche Beschreibung

make install

#Installieren ausführliche Beschreibung

In vielen Fällen reicht dies zur Installation eines Programms aus

Möchte man jedoch ein selbstkompiliertes Programm auch wieder sauber deinstallieren, sind statt `make install` Werkzeuge wie [#checkinstall checkinstall] oder porg besser geeignet

Vorbereitung

Quelltextarchive

Quelltexte werden entweder als Archivdatei zum Herunterladen angeboten (häufig wird [[tar: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 [wikipedia:Verkehrssprache: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 [size=18]#[/size] für Root-Rechte gekennzeichnet

Bei Ubuntu muss für systemweit gültige Operationen stets sudo verwendet werden

Abhängigkeiten auflösen

Fast jedes Programm hängt von [wikipedia:Programmbibliothek:Bibliotheken] ("Libraries") und/oder anderen Programmen ab

Bei der Installation eines Pakets werden diese Abhängigkeiten automatisch installiert
Für das Kompilieren eines Programms aus dem Quelltext müssen diese 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++ in der Standardinstallation enthält

Die "GNU Compiler Collection" GCC sowie weitere Werkzeuge sind im Metapaket build-essential enthalten, das über die Paketverwaltung installiert werden muss

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:

PAKETNAME

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 Dokumentation]

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

Programme für das Kompilieren und Installieren wie den Compiler oder das [wikipedia:Build-System]]
Entwicklerdateien ("Development Files") von [wikipedia:Programmbibliothek: 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 in Punkt 2 automatisch als Abhängigkeit mitinstalliert

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 [[apt/apt-cache#apt-cache-rdepends: 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 [wikipedia_en: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

Allgemeines Vorgehen

Diese Methode, deren ersten Schritte man als gängigen Standard unter Linux bezeichnen kann, beschreibt allgemeingültig das Kompilieren am Beispiel des [wikipedia:GNU_Build_System:GNU Build-System], auch bekannt als "autotools"

Vorausgesetzt wird, dass der Anwender sich innerhalb des Terminals 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

./configure

Bei Problemen bitte den Abschnitt [#Fehler-beim-Konfigurieren-mit-configure 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#Abweichende-Methoden im Abschnitt "Abweichende Methoden" behandelt

Falls das configure-Skript nicht vorhanden ist, allerdings eine Datei autogen.sh, wird das Skript durch diese andere Datei erstellt:

./autogen.sh
\

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 der Fall sein oder vom Anwender ein anderer Installationspfad gewünscht werden, kann man diesen 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 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

Bei Problemen bitte den Abschnitt [#Fehler-beim-Kompilieren-mit-make 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` ([#Die-Standard-Methode siehe unten])

Diese Art der Installation von Programmen wird für Debian-basierende Systeme mit dem [[APT: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
* 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 Allgemeines Vorgehen] sowie im Unterartikel [[Programme_kompilieren/Alternativen#Die-Debian-Methode:Die Debian-Methode]

checkinstall

Der Vorteil einer Installation mit checkinstall ist, dass ein Programm nicht an der Paketverwaltung vorbei installiert wird, sondern ein Debian-Paket im Quelltextverzeichnis erstellt und anschließend direkt installiert wird

Statt `make install` benutzt man folgenden Befehl:

sudo checkinstall

Man kann checkinstall auch ohne Root-Rechte ausführen:

checkinstall

Dann wird checkinstall zwangsläufig 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 werden

porg

porg wurde entwickelt, um ein Installationsprotokoll anzulegen, mit dessen Hilfe ein selbstkompiliertes Programm wieder sauber deinstalliert werden kann

Der Hauptunterschied zu checkinstall ist, dass kein Debian-Paket erstellt wird

Die Standard-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 (statt einer systemweiten Installation):

./configure --prefix=$HOME
make
make home-desktop-install

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 hilft auch das bereits oben erwähnte Werkzeuge porg#Problembehebung, 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 [#Weitere-Optionen 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

Problembehebung

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

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

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

Die Ausgabe weist auf die fehlende Datei alsa.pc hin

Mit dieser Information kann man jetzt in der [packages::Ubuntu Paketsuche] {en} unter "Search contents of packages" online direkt nach dieser Datei in einem Paket suchen
Als Ergebnis wird man das Paket 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 [#Abhängigkeiten-für-ein-neues-Programm 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
Im konkreten Beispiel ist die Suche über den Begriff `libgtk` am effektivsten

Die Suche kann entweder über einen grafischen Paketmanager wie Synaptic oder aber mit apt-file durchgeführt werden, 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. [[Archiv/XMMS:XMMS] sollte sich als Paket recht leicht ausfindig machen und nachinstallieren lassen – allerdings nicht unter Ubuntu, da XMMS mit [[Hardy:Ubuntu 8.04] komplett aus den offiziellen Paketquellen entfernt wurde

Speziell in diesem Beispiel ist also jedes weitere Vorgehen zum Scheitern verurteilt

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

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-Skripts, das die fehlende Komponente nicht bemerkt hat

Man muss nun herausbekommen, welches Paket die fehlende Datei enthält

Hier hilft wiederum die [packages::Ubuntu Paketsuche] {en} oder das Werkzeug apt-file
Ist das Paket gefunden und installiert, kann `make` erneut ausgeführt werden

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 folgt vor:

apt-file -l find libxtst | grep dev

Als Ausgabe erhält man das Paket libxtst-dev, welches dann zusätzlich installiert werden muss

Weblinks

Checkinstall – Pakete bauen ohne Mehraufwand {de} - LinuxUser, 07/2006
Auf zu den Quellen – Programme selber kompilieren {de} - LinuxUser, 07/2005
Sekundärsoftware aus Quellen {de} - Ubuntu GNU/Linux, Marcus Fischer, Rheinwerk <openbook>
GCC Dokumentation

GCC auf Debian

GNU Compiler Collection (GCC)

ist eine Open-Source-Sammlung
von Compilern und Bibliotheken

Programmiersprachen

C, C++, Objective-C, Fortran, Ada, Go und D unterstützen

Der Linux-Kernel, die GNU-Utilities und viele andere Projekte werden mit GCC kompiliert

Installation von GCC unter Debian

Die Standard-Debian-Repositories enthalten ein Meta-Paket namens build-essential, das den GCC-Compiler und andere Bibliotheken und Dienstprogramme enthält, die zum Kompilieren von Software benötigt werden

Folgen Sie den folgenden Schritten, um den GCC-Compiler Debian 10 zu installieren:# Aktualisieren Sie zunächst die Paketliste:

sudo apt update

Installieren Sie das build-essential Paket, indem Sie ausführen:

sudo apt install build-essential

Vielleicht möchten Sie auch die Handbuchseiten installieren, die eine Dokumentation über die Verwendung von GNU/Linux für die Entwicklung enthalten:

sudo apt-get install manpages-dev

Um zu bestätigen, dass der GCC-Compiler erfolgreich installiert wurde, geben Sie gcc --version ein:

gcc --version

Zum Zeitpunkt des Schreibens dieses Artikels ist die Standardversion von GCC, die in den Debian 10 Repositories verfügbar ist, 8.3.0:

gcc (Debian 8.3.0-6) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc
Dies ist freie Software; siehe die Quelle für die Kopierbedingungen. Es gibt KEINE
Garantie; nicht einmal für die MARKTGÄNGIGKEIT oder die EIGNUNG FÜR EINEN BESTIMMTEN ZWECK

Das war's, GCC ist erfolgreich installiert

Kompilieren eines Hello World-Beispiels

Kompilieren eines C- oder C++-Programms mit GCC

Quellcode schreiben

$ vim hello.c
hallo.c
#include <stdio.h>
int main()
{
printf ("Hallo Welt!\n");
return 0;
}

Ausführbare Datei erzeugen

$ gcc hello.c -o hello

GCC erstellt eine Binärdatei mit dem Namen hallo in dem Verzeichnis, in dem der Befehl ausgeführt wurde

Programm auszuführen

$ ./hello
Hallo Welt!