Aufmacher Artikel

Auf zu den Quellen

Programme selber kompilieren

01.07.2005 Der bekannte Dreischritt, um Programme aus dem Quelltext zu kompilieren und zu installieren, lautet "./configure", "make", "make install". Doch was verbirgt sich hinter diesen Kommandos?

Warum sollte ein Anwender ein Programm selber "backen", wenn seine Distribution vorkompilierte Pakete bereithält, seien sie im RPM- oder Debian-Format? Böse Zungen unterstellen gerne Versionitis, also den krankhaften Wunsch, stets die neueste Ausgabe eines Tools besitzen zu müssen. Doch diese Unterstellung greift zu kurz. Denn oft gelingt es erst durch das Eigenkompilat, ein Programm exakt an die eigenen Wünsche anzupassen.

Vorbereitung ist alles

Zum Kompilieren gehört ein Compiler und verschiedene andere Tools. Bevor Sie also mit der Arbeit loslegen, müssen Sie eventuell einige Werkzeuge nachrüsten. Wichtig ist in erster Linie der GNU C-Compiler gcc. Er kommt zum Einsatz, sobald Sie einen Quelltext in der Programmiersprache C vor sich haben. Um ein Programm der Sprache C++ (C-Plus-Plus) zu kompilieren, installieren Sie den GNU C++-Compiler g++.

Auch das Paket libstdc++-dev darf nicht fehlen. Es enthält die Header-Dateien zum Entwickeln von C++-Programmen. Sie benötigen diese Dateien, um die Funktionalität von Libraries dynamisch zu nutzen. Pakete mit dem Namen glibc-devel oder glibc-dev sowie libc-dev enthalten die Header-Files zum Kompilieren und Linken von C-Programmen. Je nach Distributor enden die hier angeführten Entwickler-Pakete zumeist auf -devel oder -dev.

Mit den Tools des Paketes binutils linken und assemblieren Sie Objektdateien. So befreit das Binary-Utility strip die übersetzten Dateien von überflüssigem Ballast wie Debug-Informationen und macht sie dadurch schlanker.

Um Programme mit Native Language Support (NLS) zu kompilieren, brauchen Sie das Paket gettext respektive dessen Entwicklerpaket gettext-devel. Native Language Support bedeutet, dass das installierte Programm später Fehlermeldungen und Dialoge in der von Ihnen gewünschten Sprache ausgibt.

Ebenfalls unverzichtbar ist das Tool make. Es übersetzt den Quelltext und installiert das fertige Programm anhand der Anweisungen in einer Datei mit dem Namen GNUmakefile, makefile oder Makefile. Dort stehen die Regeln samt Variablen, die make ausführt.

Als sehr nützlich kann sich das Programm patch erweisen. Es ermöglicht Ihnen das Patchen einer Software: Sie können also aus einer Datei heraus Änderungen oder Versionssprünge einspielen, ohne gleich den gesamten Quellcode einer neuen Version herunterzuladen [1].

Quellen entpacken

Dass Programme im Quelltext häufig in Tarballs verpackt vorliegen, stellt für die meisten Anwender kein Geheimnis dar. So ein Archiv mit den Sourcen entpacken Sie mittels folgendem Kommando: tar xvfz archiv-name.tar.gz

Komprimierte Tarballs mit dem Suffix .tar.bz2 öffenen Sie durch den Befehl tar xvIf archiv-name.tar.bz2 beziehungsweise mit den Optionen xvjf, je nach verwendeter Version des Tape-Archiver tar. Wenn Sie zuvor mehr über den Inhalt des Tarballs erfahren wollen, bevor Sie ihn auf Ihrer Festplatte entpacken, funktioniert das so:

[localhost]~ > tar tvfz vim-6.3-↩
lang.tar.gz | less
drwxr-xr-x mool/mool 0 2004-06-0↩
7 14:29:35 vim63/
drwxr-xr-x mool/mool 0 2004-06-0↩
7 14:29:35 vim63/src/
drwxr-xr-x mool/mool 0 2004-06-0↩
7 14:29:35 vim63/src/po/
-rw-r--r-- mool/mool 3804 2003-0↩
6-20 20:38:48 vim63/src/po/READM↩
E.txt
[…]

Lies mich!

Nach dem Öffnen des Archivs wechseln Sie in das neu entstandene Verzeichnis. Hier sehen Sie unter anderem eine Reihe von Dateien, die Namen wie configure und Makefile.in tragen oder auf .c enden. Letzteres sind Dateien mit dem Programmcode, aus dem Sie die Software später übersetzen.

Der erste Schritt zum fertigen Programm, der gerne vergessen wird, umfasst das Lesen der Textdateien README, NEWS, INSTALL und ChangeLog, soweit diese vorhanden sind. Dort finden Sie Hinweise, welche Programme oder Bibliotheken die Anwendung zu ihrer Installation benötigt. ChangeLog und NEWS informieren Sie über Veränderngen zu Vorgängerversionen. Außerdem gibt Ihnen die Datei INSTALL Tipps, wie die Installation ablaufen soll.

Falls Sie bei der Lektüre dieser Dateien auf unerfüllte Abhängigkeiten stoßen, gilt es, die entsprechenden Pakete von Ihren Distributions-CDs oder aus dem Internet nachzuinstallieren (Kasten 1). Oft finden Sie in den Dateien README oder INSTALL bereits eine URL, wo Sie das Nötige herunterladen können.

Allerdings empfiehlt sich, zunächst die distributionseigenen Resourcen zu verwenden, anstatt die Anhängigkeiten mit Hilfe des Internets aufzulösen. Nur wenn Sie eine Library nicht auf Ihren CDs entdeckten oder genau wissen, was Sie tun, sollten Sie auf distributionsfremdes Material zurückgreifen.

Ansonsten riskieren Sie Fehlfunktionen in den Programmen Ihrer Distribution, wenn diese nicht mit der von Ihnen eingespielten Bibliothek zusammenarbeiten.

Kasten 1: Datei INSTALL

Der Inhalt der Datei INSTALL variiert von Programm zu Programm. Hier sehen Sie beispielhaft die Angaben aus dem Sourcecode zum Webbrowser links.

Check you have installed the following libraries and are able to
compile with them. On a package-driven distribution, you will need both
"library" and "library-dev(el)":
libpng – required to compile links in graphics mode (not required in
text mode).
IJG libjpeg – if you want to display JPEG's (probably yes).
TIFF Library – if you want TIFFs.
SVGAlib – if you want Links to be able to display on SVGAlib.
OpenSSL – if you want SSL connections.

Make intern

Bevor Sie sich mit ./configure dem ersten Takt des Dreischritts zuwenden, sehen wir uns ein Makefile im Detail an (Listing 1). Hier entdecken Sie eine Reihe von Variablen, die den Compiler (CC) und dessen Optionen (CFLAGS) festlegen sowie das Zielverzeichnis definieren (DEST), wohin das kompilierte Programm schließlich kopiert wird. Die Manual-Seite landet über die Variablen MAN und MAN1 im Verzeichnis /usr/local/man/man1.

Listing 1

Variablen eines Makefiles

CC = gcc
CFLAGS = -O2 -Wall
DEST = /usr/local/bin
MAN  = /usr/local/man
MAN1    = $(MAN)/man1

Die Werte der Variablen DEST müssen Sie ändern, wenn Sie zum Beispiel /opt/programmname an Stelle von /usr/local/bin als Zielverzeichnis verwenden wollen. Da der Verzeichnispfad unter /usr/local/ dem User root gehört, müssen Sie vor dem Ausführen des Befehls make install mit dem Kommando su in seine Rolle schlüpfen. Ansonsten lassen sich die Pogrammteile nicht an diese Stelle kopieren.

Doch das Makefile besteht nicht nur aus Variablen: Dort stehen auch sogenannte Targets ("Ziele"). Dies sind Zeilen, die die Optionen beim Aufruf von make festlegen, beispielsweise make uninstall oder make install. Targets stehen am Anfang einer Zeile und schließen mit einem Doppelpunkt (Listing 2). Hinter dem Doppelpunkt folgen, falls vorhanden, die Voraussetzungen, die optional sind.

Listing 2

Targets eines Makefiles

uninstall:
        rm -f $(DEST)/programm
install: programm
        cp programm $(DEST)/programm

Wie Sie im Beispiel sehen, löscht der Aufruf make uninstall die Datei /usr/local/bin/programm. Die Variable DEST innerhalb dieser Regel wurde bereits in Listing 1 gesetzt. Das Kommando make install hingegen kopiert die kompilierte Datei programm in das genannte Verzeichnis. Für gewöhnlich brauchen Sie Targets nicht zu verändern. Eventuell müssen Sie Variablen wie in Listing 1 anpassen, bevor Sie die Kommandos make und make install starten.

Bei einem kleinen Makefile fällt das Editieren vor dem Kompilieren nicht ins Gewicht. Allerdings hat die Sache einen Haken: Die meisten Makefiles fallen weder klein noch übersichtlich aus. Deshalb liegt dem Quellcode in der Regel ein Shell-Skript mit dem Namen configure bei, dem wir uns nun zuwenden.

Konfiguration zur Laufzeit

Mit dem Skript configure erübrigt sich die Handarbeit am Makefile. Es prüft sogar, ob Abhängigkeiten und andere Voraussetzungen erfüllt sind, und es versteht eine Reihe von Optionen. Welche das im Einzelfalle sind, erfahren Sie über das Kommando ./configure --help | less. Die Zeichen ./ vor dem Skript-Aufruf sind wichtig, weil sich die Datei configure nicht in einem Verzeichnis der Umgebungsvariable $PATH liegt (Listing 3).

Listing 3

Die Configure-Optionen

[localhost] $ <B>./configure --help | less<B>
[…]
Optional Features:
  --enable-gpgme          Enable GPGME support
  --disable-pgp           Disable PGP support
  --without-gdbm          Don't use gdbm even if it is available
  --with-slang            Use S-Lang instead of ncurses
[…]

Die optionalen Features gliedern sich häufig in zwei Paare: enable/disable und with/without. So bedeutet bei einem Mail-Programm der Parameter --enable-pop, dass Sie die POP3-Unterstützung freischalten, während --disable-nls einen standardmäßig aktivierten NLS-Support abschaltet.

Die Optionen with/without beziehen sich gerne auf einzubindende Bibliotheken. Ein --with-ssl kompiliert zum Beispiel das Pogramm mit SSL-Unterstützung, die natürlich die Anwesenheit der SSL-Library voraussetzt.

Nach dem ersten Lauf des Shell-Skriptes sehen Sie sehr schnell, ob alle notwendigen Tools und Bibliotheken auf Ihrem System vorhanden sind. Im Beispiel in Listing 4 bemängelt configure das Fehlen der GTK-Entwicklerbibliothek libgtk2.0-dev und bricht seinen Durchlauf ab, ohne ein Makefile zu erzeugen.

Listing 4

Configure bricht ab

[localhost] $ <B>./configure<B>
checking for gcc… gcc
checking for C compiler default output file name… a.out
[…]
checking for gtk+-2.0… no
configure: error: libgtk2.0-dev missing please install libgtk2.0-dev

Jetzt hilft Ihnen ein Frontend zum Paketmanagement Ihrer Distribution weiter, beispielsweise mit einem apt-cache search libgtk. Das von Debian verwendete apt-cache ist nur eine Möglichkeit von vielen. Als Suse-Anwender steht Ihnen für solche Aufgaben das Skript pin zur Verfügung. Nun gilt es, die vermisste Library nachzuinstallieren. Als Debianer genügt Ihnen dazu der Befehl apt-get install libgtk2.0-dev.

Ein Configure-Lauf ohne Optionen kommt selten vor, denn gerade die Optionen des Befehls machen einen Selbstbau interessant. Wie Sie eine Liste der unterschiedlichen Parameter bekommen, wissen Sie inzwischen. Die interessanteste (und vermutlich die meist genutzte) Option lautet --prefix=. Mit Ihr verraten Sie make, in welches Verzeichnis es die Programmdateien kopieren soll. Beispiel: ./configure --prefix=/home/andreas/terminal.

Im obigen Beispiel landen, von der Manpage bis zur Programm, alle Dateien des Terminal-Emulators mrxvt unterhalb des Verzeichnisbaumes /home/andreas/terminal, wie die Ausgabe von make install zeigt:

[localhost] $ <B>make install<B>
[…]
/usr/bin/install -c -m 644 'TIPS↩
' '/home/andreas/terminal/share/↩
doc/mrxvt/TIPS'
[…]
/usr/bin/install -c -m 644 './mr↩
xvt.1' '/home/andreas/terminal/m↩
an/man1/mrxvt.1'
[…]
/usr/bin/install -c 'mrxvt' '/ho↩
me/andreas/terminal/bin/mrxvt'

Das Programm make ruft nun die Befehle aus dem Target install auf und kopiert so die Dateien TIPS, mrxvt.1 und mrxvt gemäß der von Ihnen gewünschten Vorgaben. Die Modus-Option -m für das Programm install ändert die Zugriffsbits [2] der kopierten Dateien. Die gesamte Installation geht über die Bühne, ohne dass Sie in diesem Fall die Rechte des Superusers root brauchen.

Damit Sie zum Start des Terminal-Emulators nicht jedesmal den vollen Verzeichnisnamen /home/andreas/terminal/bin/mrxvt eintippen müssen, nehmen Sie den Pfad in die Umgebungsvariable $PATH auf. Dazu fügen Sie die Zeile PATH=$PATH:/home/andreas/terminal/bin in die Konfigurationsdatei Ihrer Shell ein (beispielweise in der Datei ~/.bashrc). Anschließend laden Sie die neue Konfiguration mit dem Kommando . ~/.bashrc, und mrxvt lässt sich ohne Umstände in der Bash starten.

Wenn das Terminal schon als /usr/bin/mrxvt existiert und sie statt dessen Ihr mrxvt nutzen wollen, dann ändern Sie den Eintrag in PATH=/home/andreas/terminal/bin:$PATH. Jetzt findet die Shell Ihr lokales mrxvt im Heimatverzeichnis vor dem systemweiten /usr/bin/mrxvt.

Aber warum überhaupt sollten Sie als User ein Programm ins Home-Verzeichnis installieren? Einerseits spricht dafür die noch striktere Trennung von Eigenbauten und distributionseigenen Programme. Selbst bei angepassten Pfaden kann make install, dank einer Unaufmerksamkeit des Programmierers, Dateien in Bereiche des Systems kopieren, die unter der Obhut des Paketmanagements stehen. Daneben bietet dieser Weg die Möglichkeit, relativ ungefährdet Programme zu testen, die sich noch im Beta-Stadium befinden.

Ein weiterer Grund, der sich nicht auf Ihr Heimatverzeichnis beschränkt, hat mit der Sicherheit zu tun: Sowohl der Inhalt des Configure-Skripts [4] als auch des Makefiles [3] kann Ihr System ruinieren, wenn make anschließend mit den Befugnissen von root arbeitet und Angaben fehlerhaft sind.

Vermeiden Sie es darum, mit Administrator-Rechten den Einzeiler ./configure && make && make install in die Shell zu tippen – es könnte der letzte Befehl sein, den Ihr Rechner von Ihnen akzeptiert. Die Befehle configure und make gehören in die Hände eines Users. Erst dann kommt root mit make install zum Zuge. Auf diese Weise werden Sie noch lange Freude an Ihrem freien Betriebssystem haben.

Infos

[1] Wiki-Eintrag "Patch": http://www.vdr-wiki.de/wiki/index.php/Patches

[2] Heike Jurzik, Gleiches Recht für alle?, LinuxUser 07/2004, S. 69: http://www.linux-user.de/ausgabe/2004/07/069-zubefehl/

[3] "rm -rf $DIR /" im Makefile: http://www.theparallax.org/dcoul/user2root/stories.shtml

[4] Hintertür im configure-Skript des ICQ-Cients Irssi: http://real.irssi.org/?page=backdoor

Tip a friend    Druckansicht beenden Bookmark and Share
Kommentare