Nirgendwo lauern so viele Fehlermeldungen wie beim Kompilieren von Software. Besonders kritisch sind configure-Skripte – Zeit für einen Wegweiser aus dem Fehlerlabyrinth.

Früher oder später erlebt es jeder Linux-Nutzer: Ein heißbegehrtes Programm gibt es nicht als fertiges Paket für die eigene Distribution. Erfahrene Linuxer sind mit dem Ratschlag “Dann kompilier es doch einfach selbst!” schnell bei der Hand. Statt des neuen Programms warten auf ambitionierte Jungkompilierer jedoch meistens nur haufenweise Fehlermeldungen. Da wirft manch einer die Flinte ins Korn und kommt zu dem Schluss, man müsse programmieren können, um Software erfolgreich zu übersetzen.

Das stimmt glücklicherweise nicht, denn der Kompilierprozess ist bei den meisten Anwendungen weitgehend automatisiert. Wer wissen will, wie der aussieht und was bei den drei Schritten ./configure, make und make install passiert, informiert sich in [1] über die Grundlagen.

Der vorliegende Artikel widmet sich den Fehlermeldungen, die Ihnen beim ./configure-Aufruf begegnen. Denn um Software selbst zu übersetzen, ist es wichtig zu wissen, wie man deren Ursache abstellt.

Grundausstattung

Haben Sie den Quellcode einer Anwendung heruntergeladen und entpackt, ist das dabei entstandene Verzeichnis Ihr Arbeitsplatz. Der erste Blick sollte dort den Dateien README und INSTALL gelten. Darin steht, ob Sie das Programm tatsächlich mit dem klassischen Dreisatz übersetzen oder ob Sie zuvor eine Datei bearbeiten müssen. Viele Programmierer verraten hier ebenfalls, ob Sie weitere Software für das Programm benötigen.

Wer anschließend zum ersten Mal auf seinem System den Befehl ./configure eingibt, bei dem bricht das Shell-Skript oft schon kurz nach dem Aufruf mit diesen Meldungen ab:

checking for gcc… no
checking for cc… no
checking for cc… no
checking for cl… no
configure: error: no acceptable C compiler found in $PATH

Es schaut nach, ob alle Dateien vorhanden sind, die Sie brauchen, um die Software zu übersetzen. Was es prüft, steht in den mit checking beginnenden Zeilen. An deren Ende folgt das Ergebnis, hier no, also “nein”. Da das Skript erfolglos gesucht hat, beendet es sich und präsentiert eine Fehlermeldung. Selbst wer kein Englisch spricht, übersetzt sie schnell mit einem Wörterbuch: keinen passenden C-Compiler im $PATH gefunden.

Die Variable PATH (dass es eine Variable ist, erkennen Sie am vorangestellten Dollar-Zeichen, einem Operator, der ihren Inhalt anfordert) enthält den Suchpfad für ausführbare Programme. Welche Verzeichnisse er umfasst, variiert von Distribution zu Distribution. Der Befehl echo $PATH zeigt sie an.

Das nicht auffindbare Programm ist ein C-Compiler, die Anwendung, die in der Sprache C geschriebene Software in ein ausführbares Programm übersetzt. Unter Linux kommt dafür gewöhnlich der gcc zum Einsatz. Dieses unentbehrliche Werkzeug installiert mittlerweile fast keine Distribution mehr standardmäßig mit.

Tabelle 1 listet die Pakete auf, mit denen Sie Ihr System fit fürs Kompilieren machen. Dazu gehören nicht nur das Handwerkszeug wie der Compiler und das Programm make, sondern auch Entwicklerpakete, die Dateien enthalten, die Sie beim Übersetzen grafischer Anwendungen brauchen.

Lassen Sie sich nicht von der Paketbeschreibung dieser Devel-Pakete verwirren: Sie suggeriert, Sie brauchten diese Dateien nur, um selbst Software zu schreiben. Allerdings sind sie auch nötig, um fertig geschriebenen Quellcode zu übersetzen.

Spielen Sie die Entwicklerpakete über die Paketverwaltung Ihrer Distribution ein (Abbildung 1)! Wer die Personal-Version von Suse Linux verwendet, muss die meisten davon vom Suse-FTP-Server herunterladen: Dieses Produkt bringt nämlich fast keine Entwicklerpakete mit.

Abbildung 1: In der Kategorie “Entwicklung” finden Sie bei Suses Yast die Pakete, die Sie zum Kompilieren brauchen.

Eine solche Grundausstattung eliminiert die Ursache der meisten Fehlermeldungen. Tauchen nun noch welche auf, ist ein wenig detektivisches Gespür gefragt.

Wer suchet, der findet

Den wohl häufigsten Typ von configure-Fehlermeldungen zeigt Listing 1.

[andi@diabolos squaroid-0.60.3]./configure[…]
checking for GTK - version >= 1.2.0… yes
checking for imlib-config… no
checking for gdk_imlib… not found
configure: error: Cannot find gdk_imlib: I NEED IT!

Das Konfigurationsskript beschwert sich hier über eine fehlende gdk_imlib (bei Ihrer Wunschanwendung fehlt stattdessen vielleicht krb5.h oder lidSDL.so). Die Zeile checking for imlib-config... no enthält das Prüfkriterium: configure sucht nach dem Skript imlib-config. Da es das nicht findet – no –, kommt es zu dem Schluss, dass es gdk_imlib auf dem System nicht gibt (checking for gdk_imlib... not found).

Ob die Datei imlib-config auf Ihrem System tatsächlich fehlt oder configure nur schlecht gesucht hat, erfahren Sie mit locateimlib-config. Alternativ benutzen Sie find[4], das jedoch wesentlich länger sucht, da es nicht auf eine Datenbank zurückgreift.

Verläuft die Suche ergebnislos, fehlt die Datei also tatsächlich, gilt es, sie nachzuinstallieren. Aber wie erfährt man, in welchem der unzähligen Distributionspakete sie sich befindet? Unter Mandrake und Suse Linux ist das dank der mitgelieferten Tools ein Kinderspiel: Wer Mandrake verwendet, tippt den Befehl urpmf imlib-config ein. Der Paketverwalter durchforstet daraufhin seine Datenbank und zeigt Ihnen, welche Dateien imlib-config enthalten und in welchem Paket sie stecken (Abbildung 2). Ein zusätzliches urpmf gdk_imlib verrät, dass auch die Entwicklerdateien im Paket libimlib1-devel liegen.

pin zurück. Beim ersten Aufruf fordert es das Installationsmedium an, um die Archivdatei mit der Paketübersicht auf die Festplatte zu kopieren. Dieses Mal müssen Sie sich daher als Administrator authentifizieren. Danach verrät Ihnen der Aufruf pin imlib-config, dass das gleichnamige Paket die Datei enthält. pin gdk_imlib liefert imlib-devel als Treffer. Unter Suse Linux installieren Sie diese beiden Pakete, damit configure nicht mehr abbricht.” width=”300″ height=”108″ /> Abbildung 2: Unter Mandrake sucht “urpmf” in einer Datenbank, die eine Dateiliste für alle distributionseigenen RPM-Pakete enthält.Unter Suse Linux greifen Sie auf pin zurück. Beim ersten Aufruf fordert es das Installationsmedium an, um die Archivdatei mit der Paketübersicht auf die Festplatte zu kopieren. Dieses Mal müssen Sie sich daher als Administrator authentifizieren. Danach verrät Ihnen der Aufruf pin imlib-config, dass das gleichnamige Paket die Datei enthält. pin gdk_imlib liefert imlib-devel als Treffer. Unter Suse Linux installieren Sie diese beiden Pakete, damit configure nicht mehr abbricht.

Schwerer haben es alle, die die Personal-Version von Suse oder Red Hat Linux verwenden. Red Hat bringt gar kein Programm mit, mit dem man in der Dateiliste noch nicht installierter Pakete suchen kann. Bei Suse Personal führt die Suche nach Entwicklerdateien meistens ins Leere, da die nötigen Pakete nicht auf den CDs dabei sind.

Eine Alternative für diese Fälle bietet die Suchmaschine für RPM- und Debian-Pakete unter [2]. Das Formular fahndet auch nach einzelnen Dateien und zeigt die Pakete an, die sie enthalten (Abbildung 3). Debianer werden zudem unter http://packages.debian.org/ fündig.

Abbildung 3: Rpmseek.com sucht nicht nur nach Paketen, sondern akzeptiert auch Dateinamen als Suchbegriff.

Gut versteckt

Ein kniffeligeres Problem haben Sie, wenn ./configure Dateien nicht findet, obwohl sie auf dem System vorhanden sind. Der Grund dafür kann sein, dass Sie die benötigte Bibliothek selbst übersetzt haben oder eine Distribution verwenden, die die Dateien in ein ungewöhnliches Verzeichnis packt, wo configure nicht danach sucht. Ein Beispiel dafür sehen Sie in Listing 2.

[andi@diabolos ogle-0.9.1]$ ./configure[…]
checking for madvise… yes
checking for DVDDiscID in -ldvdread… no
checking for DVDOpen in -ldvdread… no
configure: error: Need libdvdread, install it or specify it's location

Dort vermisst configureldvdread. Das ist nicht etwa der Name der vermissten Datei – expandieren Sie das l am Anfang einfach zu lib und hängen Sie .so an, schon haben Sie den Namen: libdvdread.so. Dateien, deren Name mit lib beginnt, gehören zu Programmbibliotheken, die viele verschiedene Anwendungen nutzen können.

Die vermisste ldvdread stammt aus dem libdvdread-Paket, das wir selbst kompiliert und nach /usr/local/multimedia installiert haben. Tatsächlich liegt, wie locate libdvdread.so verrät, im Verzeichnis /usr/local/multimedia/lib die Datei libdvdread.so, nach der configure sucht.

Es findet sie nicht, da /usr/local/multimedia kein Standardverzeichnis für Software-Installationen ist. Trotzdem ist es manchmal sinnvoll, ein solches zu verwenden, z. B. wenn man eine Anwendung nur testen und danach gleich wieder löschen will, oder wenn man nicht der Administrator des Rechners ist und daher nicht überall Schreibrechte hat.

In Listing 2 gibt configure sogar einen Lösungshinweis: configure: Fehler: Brauche libdvdread, installier sie oder gib den Speicherort an. Installiert ist das gute Stück bereits, also kommt nur der zweite Vorschlag in Frage. Wie Sie den Speicherort spezifizieren, verrät

./configure --help | less

Mit --help aufgerufen, zeigt configure alle Aufrufparameter an, die es kennt, und gibt jeweils eine kurze Erklärung (vgl. auch [1]). So legt der Parameter --prefix fest, wo die Software bei der Installation landet, standardmäßig ist das meistens das Verzeichnis /usr/local. Da die gezeigte Befehlszeile die Hilfe im Pager less[5] öffnet, können Sie mit Eingabe von /dvdread nach dem passenden Parameter suchen (Abbildung 4). Für unser Beispiel ist

./configure --with-dvdread=/usr/local/multimedia

die richtige Wahl. Als Pfad erwartet configure immer das Präfix, in das Sie eine Anwendung installiert haben.

Abbildung 4: “./configure –help” listet alle Parameter auf, die das Konfigurationsskript kennt.

Viele Möglichkeiten

Manche configure-Skripte geben Ihnen genauere Hinweise, wie Sie einer Fehlermeldung zu Leibe rücken. So beendet sich configure im Beispiel aus Listing 3 mit einem Fehler, da es die Datei sdl-config nicht findet.

[andi@diabolos lbreakout2-2.5beta-3]$ ./configure[…]
checking for main in -lpng… yes
checking for sdl-config… no
checking for SDL - version >= 1.2.0… no
 * The sdl-config script installed by SDL could not be found
 * If SDL was installed in PREFIX, make sure PREFIX/bin is in
 * your path, or set the SDL_CONFIG environment variable to the
 * full path to sdl-config.
configure: error: libSDL is needed

Zuerst überprüfen Sie nun, ob diese Datei überhaupt installiert ist. Die Anwendung stammt (auf einem Mandrake-System) aus dem Paket libSDL1.2-devel. Gibt es die Datei bei Ihnen bislang nicht, lösen Sie das Problem am einfachsten, indem Sie das Päckchen einspielen – dann beschwert configure sich nicht mehr.

Liegt sdl-config schon als Selbstkompilat auf der Festplatte, hilft configure mit Tipps weiter, die in den mit Sternchen beginnenden Zeilen stehen. sdl-config ist ein Skript, das configure verrät, wo die aktuelle SDL-Installation liegt und welche Compiler-Flags ins Makefile gehören. Damit configure dieses Skript findet, muss es im Suchpfad für Programme liegen, dem PATH. Liegt sdl-config in /usr/local/games/bin, hängen Sie dieses Verzeichnis mit dem Befehl

export PATH=$PATH:/usr/local/games/bin

an den bisherigen Pfad an. Der Ausdruck $PATH direkt hinter dem Gleichheitszeichen sorgt dafür, dass Sie den alten Suchpfad nicht überschreiben, sondern aus ihm und dem zusätzlichen Verzeichnis /usr/local/games/bin den neuen zusammenbasteln. Der Doppelpunkt fungiert dabei als Trenner zwischen zwei Verzeichnisangaben. Um /usr/local/games/bin dauerhaft in den Suchpfad aufzunehmen, schreiben Sie den obigen Befehl z. B. in die Startdatei der Bash namens .bash_profile in Ihrem /home-Verzeichnis.

Alternativ setzen Sie die Umgebungsvariable SDL_CONFIG. Das geht ebenfalls mit dem Befehl export:

export SDL_CONFIG=/usr/local/games/bin/sdl-config

Als Wert weisen Sie ihr den vollen Pfad (in Listing 3: full path to sdl-config) zur Datei sdl-config zu.

Variablenwirtschaft

In letzter Zeit übernimmt immer öfter pkg-config die Arbeit bibliothekseigener Konfigurationsskripte wie sdl-config. Dabei handelt es sich um eine Hilfsanwendung für Programmierer, die herausfindet, wo eine Bibliothek liegt und welche Parameter nötig sind, um sie beim Übersetzen von Programmen zu nutzen.

Seine Informationen bezieht das pkg-config-Werkzeug aus einfachen Textdateien mit der Endung .pc, die normalerweise im Verzeichnis /usr/lib/pkconfig liegen. Sie enthalten unter anderem die installierte Version einer Bibliothek und die Pfade zu den Include-Dateien und den Bibliotheken (Abbildung 5).

Abbildung 5: Aus der Datei “gtk+.pc” erfährt “pkg-config” alles Nötige über die installierte GTK-Version.

Haben Sie eine Bibliothek, z. B. die libgphoto zur Ansteuerung von Digitalkameras, selbst kompiliert, landen die Dateien per Default unterhalb des Verzeichnisses /usr/local. Die Datei libgphoto2.pc kopiert der make install-Aufruf nach /usr/local/lib/pkgconfig. Übersetzen Sie danach eine Anwendung, die diese Bibliothek benötigt, konfrontiert Sie ./configure mit einer Fehlermeldung wie in Listing 4.

[andi@diabolos gphoto2-2.1.1]$ ./configure[…]
checking for libgphoto2 >= 2.1.1… Package libgphoto2 was not found in the pkg-config search path.
Perhaps you should add the directory containing `libgphoto2.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libgphoto2' found
configure: error: Library requirements (libgphoto2 >= 2.1.1) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them.

Auf den richtigen Pfad gebracht

Das configure-Skript glaubt, libgphoto2 sei nicht in einer ausreichend hohen Version installiert (Library requirements (libgphoto2 >= 2.1.1) not met). Es kommt zu diesem Schluss, da es libgphoto2.pc nicht im pkg-config search path gefunden hat. Offenbar gibt es also einen Suchpfad (search path), in dem pkg-config nach den pc-Dateien fahndet.

configure gibt sich in Listing 4 auskunftsfreudig und verrät, dass Sie ihn über die Umgebungsvariable PKG_CONFIG_PATH erweitern können. Es sagt auch, welches Verzeichnis in den Suchpfad gehört, nämlich das, in dem libgphoto2.pc liegt ( Vielleicht sollten Sie das Verzeichnis, das libgphoto2.pc enthält, zur PKG_CONFIG_PATH-Umgebungsvariable hinzufügen).

Umgebungsvariablen setzen Sie, wie oben gezeigt, mit dem Befehl export. Der Aufruf

export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/lib/pkgconfig

bildet den pkg-config-Suchpfad aus den Verzeichnissen /usr/local/lib/pkgconfig, wo libgphoto2.pc liegt, und /usr/lib/pkgconfig, dem Standardsuchpfad. Der muss nicht unbedingt in der Umgebungsvariable auftauchen, da pkg-config dort auf jeden Fall sucht.

Wer öfters Programme kompiliert, setzt den PKG_CONFIG_PATH dauerhaft über die Datei ~/.bash_profile. Stimmt er, findet das configure-Skript, das pkg-config aufruft, auch die selbst installierte libgphoto2 (Abbildung 6).

Abbildung 6: Mit richtig gesetztem “PKG_CONFIG_PATH” liefert “pkg-config” dem “configure”-Skript die richtigen Informationen.

Noch mehr Hilfe

Leider gibt es configure-Fehler, die die Beispiele nicht erfassen. Entweder bietet das Skript keine passenden Optionen oder dem Programmierer ist ein Flüchtigkeitsfehler unterlaufen. Kommen Sie einmal nicht weiter, gibt es dennoch ein paar Auswege: Manchmal hilft ein Blick in die Datei config.log im Quellcode-Verzeichnis weiter. Dort protokolliert configure alle Befehle, die es ausführt, und deren Ausgabe.

Hilft auch die Log-Datei nicht, führt vielleicht die Eingabe der Fehlermeldung in eine Suchmaschine wie Google zum Erfolg. Gerade in Newsgruppen [3] finden Sie oft Anwender, die dasselbe Problem hatten – und eine passende Lösung. Als letzter Ausweg bietet sich eine Nachfrage beim Entwickler des Programms an. Dessen Adresse steht in der Datei AUTHORS; in BUGS oder README finden Sie oft eine Anleitung, welche Informationen der Programmierer braucht, um Ihnen bei einem Problem zu helfen.