Sei es ein in “out of the box” vorgestelltes Programm, sei es sonstige Software – im Quellcode vorliegende Programme unter Linux zu kompilieren und zu installieren ist nur selten wirklich schwierig. Da stellt sich die Frage: Wie wird eigentlich ein solches Sourcecode-Paket zusammen gestellt, damit auch alles klappt?

Ein großer Vorteil freier Software liegt darin, dass jeder die Möglichkeit zum Studium des Programmcodes hat und ihn an eigene Bedürfnisse anpassen kann. Damit sich nun aber nicht jeder, der eine freie Software installieren möchte, zwangsläufig mit den Programmquellen auseinandersetzen muss, gibt es Tools, die dem Benutzer die Anpassungsarbeit an das eigene System abnehmen.

Das Einmaleins der Installation

Software, die unter die GNU General Public Licence oder eine andere Open-Source-Lizenz fällt, wird meist in Form mehr oder weniger großer “gezippter” tar-Archive bereit gestellt. Wer ein solches Paket installieren möchte, muss es zunächst auf der eigenen Festplatte entpacken.

Als Beispiel soll hier das GIMP-Toolkitgtk+-1.2.2.tar.gz dienen:

gunzip gtk+-1.2.2.tar.gz
tar xf gtk+-1.2.2.tar

Diese zwei Schritte – der erste dekomprimiert die tar.gz-Datei zu einem reinen tar-Archiv, der zweite entpackt das dadurch erzeugte File – lassen sich mit der unter Linux gebräuchlichen tar-Version auch zu einem zusammenfassen:

tar xzf gtk+-1.2.2.tar.gz

Dabei erhält man ein Verzeichnis mit dem Namen gtk+-1.2.2, in dem sich die einzelnen Dateien und Unterverzeichnisse des Pakets befinden. Nachdem man in das soeben erzeugte Verzeichnis gewechselt ist, kann man mit der eigentlichen Arbeit beginnen.

Zunächst startet man das configure-Skript:

./configure

Dadurch passt der Anwender die Software – oder vielmehr die zur Übersetzung benötigten Makefiles – automatisch an das eigene System an. Wie ein solches configure-Skript entsteht, sehen wir etwas später.

Trat ein Fehler auf, kann dies zum Beispiel an einer Library liegen, die für die Programmgenerierung benötigt wird, jedoch nicht oder in einer veralteten Version installiert ist. Diese muss dann zunächst eingespielt werden. Wenn die Konfiguration ohne Fehlermeldung ablief, kann mit dem Kompilieren der Programmquellen begonnen werden. Nach Eingabe von

make

wird der Quellcode übersetzt. Bei großen Programmpaketen, wie dem hier als Beispiel angeführten gtk+-1.2.2, ist spätestens jetzt die Zeit für eine Teepause gekommen. Das Kompilieren dieses Pakets dauert auf einem Pentium 266 beispielsweise ganze 13 Minuten.

Ging beim Kompilieren alles glatt, müssen die neu erzeugten Dateien an die “richtige” Stelle kopiert werden. Für ausführbare Binärdateien kann dies zum Beispiel das Verzeichnis /usr/local/bin sein. Man verschafft sich also root-Rechte und startet den Kopiervorgang:

su
make install

Jetzt sollte jeder “normale” User das neu installierte Programm durch Eingabe des entsprechenden Namens starten können. Da es sich bei unserem Beispiel um eine Library handelt, können wir allerdings gar nichts ausführen.

Möchte man ein neues Paket auf einem Rechner installieren, auf dem man selbst keine root-Rechte besitzt, entfällt natürlich der letzte Schritt, und man muss das Programm direkt aus dem entsprechenden Unterverzeichnis heraus aufrufen (oder z.B. einen symbolischen Link setzen). Der Kasten “Installationsdreiklang” fasst alle Schritte noch einmal kurz zusammen.

./configure

make

su
make install

Jetzt wissen wir also, wie man als Anwender einen Sourcecode übersetzt und zum “Laufen” bringt. Was aber ist alles nötig, um solch ein Paket zu erstellen?

Wo soll das nochmal enden?

Damit die Installation wirklich so reibungslos wie oben beschrieben funktioniert, müssen verständlicherweise einige Konventionen beim Erstellen der Quellpakete beachtet werden. Jede GNU-Software wird deshalb (normalerweise) in einer festgelegten Verzeichnisstruktur abgelegt und mit ein paar Standarddateien versehen. Auch wenn man sein Programm unter einer anderen Lizenz freigeben will, bietet sich eine entsprechende Strukturierung an. Tabelle 1 zeigt, wie diese aussehen sollte. Die angegebenen Verzeichnisse befinden sich alle unterhalb des eigentlichen Projektverzeichnisses. Es müssen keineswegs immer sämtliche Directories verwendet werden – einige sind optional.

Bei den in Tabelle 2 aufgeführten Dateien handelt es sich um allgemeine Dokumentation, die auf jeden Fall im Projektverzeichnis vorhanden sein muss. Für jede dieser Dateien ein Beispiel abzudrucken würde an dieser Stelle jedoch den Platz sprengen. Aber da sie in den verschiedenen GNU-Software-Paketen ohnehin enthalten sind, werfen Sie doch einfach bei Ihrer nächsten Kompilieraktion einen Blick darauf!

Abbildung 1 zeigt ein Sourcecode-Paket mit einigen der eben beschriebenen Verzeichnisse und Dateien.

Abbildung 1: Eine typische Datei- und Verzeichnisstruktur

Das Handwerkszeug

Nach all der Theorie wird es nun langsam Zeit für die Praxis. Bevor wir aber mit dem Erstellen eines eigenen Programmpakets beginnen können, müssen wir sicher stellen, dass wir die dafür notwendigen Tools installiert haben. Um das GNU-Build-System nutzen zu können, benötigen wir folgende Programme:

• autoconf
• automake
• libtool
• optional acmkdir

Das Programm acmkdir liegt dem Paket autotools bei und ist für die Arbeit mit den anderen Tools nicht zwingend erforderlich. Was es damit auf sich hat, erkläre ich später noch. Ob die Werkzeuge auf dem eigenen System bereits installiert sind, kann man einfach testen, indem man ihre Versionsnummer abruft. Auf meinem System sieht das zum Beispiel so aus:

/home/klaus > autoconf --version
Autoconf version 2.13
/home/klaus > automake --version
automake (GNU automake) 1.4
Copyright (C) 1999 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Tom Tromey <tromey@cygnus.com>
/home/klaus > libtool --version
ltmain.sh (GNU libtool) 1.3 (1.385.2.117 1999/04/29 13:07:13)
/home/klaus > acmkdir --version
automkdir 0.10 - Generate directory tree for new software package
Copyright (C) 1997 Eleftherios Gkioulekas <lf@amath.washington.edu>
This is free software, and you are welcome to redistribute it and modify it
under certain conditions. There is ABSOLUTELY NO WARRANTY for this software.
For legal details see the GNU General Public License.

Ist ein Programm nicht vorhanden, sollte man schauen, ob es nicht der auf dem System installierten Linux-Distribution beiliegt. Wenn ja, installiert man es von dort. Falls das nicht der Fall sein sollte, kann man sich das gewünschte Sourcecodepaket aus dem Internet laden [1] und hoffentlich spätestens nach der Lektüre dieses Artikels selbst entpacken, konfigurieren, kompilieren und installieren. Außerdem müssen die Programme make, m4 und tar vorhanden sein, welche aber auf jedem Linux-System installiert sein dürften.

Hallo GNU!

Damit uns jetzt nicht auch noch der letzte Leser einschläft, fangen wir endlich mit dem Erstellen unserer eigenen kleinen Sourcecode-Distribution an. Unser Programm soll den Namen hello_GNU tragen. Seine Funktion dürfte zwar in die Kategorie “Sinnlos” einzuordnen sein, aber es geht uns hier ja schließlich nicht ums Programmieren. Zuerst erstellen wir ein Verzeichnis hello_GNU-0.1:

/home/klaus > mkdir hello_GNU-0.1
/home/klaus > cd hello_GNU-0.1

Danach scheiben wir mit einem beliebigen Editor ein kleines C-Programm, das nichts weiter tut, als hello G N U zu sagen (Listing 1).

/***************/
/* hello_GNU.c */
/***************/
#include <stdio.h>
void main (void)
{
 printf("\n");
 printf("hello  G N U \n");
}

Da wir in unserem Beispiel nur eine Quelldatei verwenden, können wir auf das Erzeugen des src-Verzeichnisses verzichten und sie direkt in unserem Projektverzeichnis ablegen. Als Nächstes erstellen wir die Datei Makefile.am (Listing 2).

bin_PROGRAMS = hello_GNU
hello_GNU_SOURCES = hello_GNU.c

Die Variable bin_PROGRAMS gibt den Namen der mit Hilfe von make zu erzeugenden Binärdatei an. Diese wird beim Installieren mit make install nach /PREFIX/bin kopiert, wobei PREFIX gewöhnlich durch /usr/local/ ersetzt wird.

hello_GNU_SOURCES listet alle zur Programmerzeugung benötigten Dateien auf. In unserem Beispiel ist dies nur die Datei hello_GNU.c. Hieße unser Beispielprogramm nicht hello_GNU, sondern example, so müsste hello_GNU_SOURCES durch example_SOURCES ersetzt werden.

Makefile.am enthält also die Namen sowohl der Sourcen als auch der ausführbaren Datei.

Jetzt erzeugen wir eine Datei namens configure.in (Listing 3).

AC_INIT(hello_GNU.c)
AM_INIT_AUTOMAKE(hello_GNU,0.1)
AC_PROG_CC
AC_PROG_INSTALL
AC_OUTPUT(Makefile)

AC_INIT initialisiert darin das configure-Skript. Als Argument schreibt man den Namen einer Quelldatei in Klammern. Sind mehrere Quelldateien vorhanden, genügt es, eine davon anzugeben.

AM_INIT_AUTOMAKE(hello_GNU,0.1) legt die “Startwerte” für automake fest. Dies sind der Name unseres Programmpakets, durch Komma getrennt von der Versionsnummer (Leerzeichen dazwischen sind erlaubt). Letztere muss mit der Endung des Verzeichnisnamens unseres Projekts (also 0.1 bei hello_GNU-0.1) übereinstimmen.

Die AC_PROG-Anweisungen suchen nach Programmen, die von System zu System unterschiedlich sein können. In unserem Fall suchen wir nur nach einem C-Compiler (AC_PROG_CC) sowie nach einem Installationstool (AC_PROG_INSTALL).

AC_OUTPUT(Makefile) gibt schließlich die vom configure-Skript zu erzeugende Datei, nämlich Makefile an.

Schließlich erstellen wir noch einige benötigte Dokumentationsdateien:

/home/klaus/hello_GNU-0.1 > touch NEWS README AUTHORS ChangeLog

Diese leeren Dateien kann später jeder selbst mit Inhalt füllen. Unser Verzeichnis sollte nun etwa so aussehen:

/home/klaus/hello_GNU-0.1 > ls -l
total 3
-rw-r--r--  1 klaus   users     0 Dec 10 15:46 AUTHORS
-rw-r--r--  1 klaus   users     0 Dec 10 15:46 ChangeLog
-rw-r--r--  1 klaus   users    57 Dec 10 15:16 Makefile.am
-rw-r--r--  1 klaus   users     0 Dec 10 15:46 NEWS
-rw-r--r--  1 klaus   users     0 Dec 10 15:46 README
-rw-r--r--  1 klaus   users   101 Dec 10 15:28 configure.in
-rw-r--r--  1 klaus   users   141 Dec 10 14:54 hello_GNU.c

Damit ist endlich der Zeitpunkt gekommen, um unser Programmpaket zu erzeugen:

/home/klaus/hello_GNU-0.1 > aclocal
/home/klaus/hello_GNU-0.1 > autoconf

Mit dem Aufruf von autoconf erstellen wir das bereits am Anfang dieses Artikels erwähnte configure-Skript. Wer möchte kann es sich mit einem Texteditor anschauen. Es handelt sich dabei um ein sehr komplexes Shellskript, dessen Verständnis für die weitere Arbeit jedoch keinesfalls erforderlich ist.

/home/klaus/hello_GNU-0.1 > automake -a
automake: configure.in: installing `./install-sh'
automake: configure.in: installing `./mkinstalldirs'
automake: configure.in: installing `./missing'
automake: Makefile.am: installing `./INSTALL'
automake: Makefile.am: installing `./COPYING'

Jetzt befindet sich unser Dateibaum bereits in dem Zustand, in dem ihn ein Anwender vorfindet, der unser Softwarepaket beispielsweise aus dem Netz geladen und entpackt hat. Probieren wir nun aus, ob wir unser Programm mit den automatisch erzeugten Dateien tatsächlich konfigurieren und kompilieren können:

/home/klaus/hello_GNU-0.1 > ./configure
creating cache ./config.cache
checking for a BSD compatible install... /usr/bin/ginstall -c[Ausgabe gekürzt]
/home/klaus/hello_GNU-0.1 > make
gcc -DPACKAGE=\"hello_GNU\" -DVERSION=\"0.1\"  -I. -I.      -g -O2 -c hello_GNU.c
hello_GNU.c: In function `main':
hello_GNU.c:8: warning: return type of `main' is not `int'
gcc  -g -O2  -o hello_GNU  hello_GNU.o

Abgesehen von der Compilerwarnung, die uns hier nicht stört, hat alles gut funktioniert. Unser Programm sollte nun nur noch lauffähig sein:

/home/klaus/hello_GNU-0.1 > ./hello_GNU
hello  G N U

Jawohl – es funktioniert! Wenn wir es jetzt noch installieren, kann jeder Benutzer unseres Systems von jedem beliebigen Verzeichnis aus davon Gebrauch machen:

/home/klaus/hello_GNU-0.1 > su
Password: [streng geheimes root-Passwort]
/home/klaus/hello_GNU-0.1 # make install
make[1]: Entering directory `/home/klaus/hello_GNU-0.1'
/bin/sh ./mkinstalldirs /usr/local/bin
  /usr/bin/ginstall -c  hello_GNU /usr/local/bin/hello_GNU-0.1
make[1]: Nothing to be done for `install-data-am'.
make[1]: Leaving directory `/home/klaus/hello_GNU-0.1'

Nachdem wir unser Programm nun systemweit installiert, ausgiebig getestet und für gut befunden haben, wollen wir es per Internet der großen, weltweiten Schar potentieller Nutzer zur Verfügung stellen. Dazu benötigen wir ein tar-Archiv mit den entsprechenden Dateien. Auch das wird automatisch für uns erzeugt:

/home/klaus/hello_GNU-0.1 > make distcheck
rm -rf hello_GNU-0.1
mkdir hello_GNU-0.1
chmod 777 hello_GNU-0.1
here=`cd . && pwd`; \
top_distdir=`cd hello_GNU-0.1 && pwd`; \
distdir=`cd hello_GNU-0.1 && pwd`; \[Ausgabe gekürzt]
make[1]: Leaving directory `/home/klaus/hello_GNU-0.1/hello_GNU-0.1/=build'
rm -rf hello_GNU-0.1
==============================================
hello_GNU-0.1.tar.gz is ready for distribution
==============================================
/home/klaus/hello_GNU-0.1 > ls hello*gz
hello_GNU-0.1.tar.gz

Diese so erhaltene Datei kann man nun, wenn es denn unbedingt sein muss, in die ganze Welt verschicken. Jeder andere Unix-Nutzer (und damit auch jeder, der Linux verwendet) ist damit in der Lage, das hello_GNU-Programm auf seinem Computer zu übersetzen und auszuführen – egal, auf welcher Hardware er arbeitet.

Automation ohne Ende

Für alle, denen es zuviel Handarbeit ist, die Verzeichnisstruktur sowie die zugehörigen Dokumentationsdateien bei jedem Projekt wieder neu zu erstellen, gibt es das Programm acmkdir[7].

/home/klaus/tmp > acmkdir hello_GNU
Ready to create a new distribution skeleton directory.
The current working directory is:
 --> /home/klaus/tmp
If you make a mistake and need to abort, press ctrl-C.
Name of distribution: hello_GNU
Your full name:       klaus konzept
Your email address:   klaus.konzept@unknown.de
Do you want to proceed? (y/n) y
+ Mode is default
+ Making directory hello_GNU
+ Running reconf
./reconf: ./reconf: cannot execute binary file
Distribution directory is ready.
Please make sure to keep the files AUTHORS, NEWS, README, THANKS up to
date before cutting a distribution.

Nach Eingabe des Distributions- bzw. Projektnamens, des eigenen Namens sowie der eigenen E-Mail-Adresse erledigt acmkdir den Rest der Arbeit. Wer Lust hat, selbst komplexere Programmpakete als das hier beschriebene zu erstellen, sollte sich die entsprechenden Manuals besorgen (vgl. dazu den “Info”-Kasten). Eine sehr gelungene Einführung in die Thematik stammt meiner Meinung nach von Eleftherios Gkioulekas [6], dem Autor von acmkdir.