Dr. Linux
Komplizierte Organismen, wie Linux-Systeme es nun einmal sind, haben so ihre ganz eigenen Wehwehchen. Für diese Ausgabe kramt Frau Dr. Linux im Redaktionspostfach mailto:redaktion@linux-user.de und bietet Heilung für drängende KDE-Installationsprobleme an.
Nicht ohne die passende Bibliothek
Ich habe versucht, ein KDE-Programm von der Heft-CD zu installieren, aber nach dem ./configure bekomme ich die Fehlermeldung
checking for Qt… configure: error: Qt (>= Qt 3.0.2) (headers and libraries) not found. Please check your installation!
Was läuft hier schief?
Dr. Linux: Betrachtet man die Meldung in Einzelschritten, kommt man der Lösung des Problems schnell näher: error: Qt (>= Qt 3.0.2) teilt mit, dass die Qt-Bibliothek nicht in einer Version größer gleich 3.0.2 installiert ist. Da sich die Programmierschnittstellen von verschiedenen Bibliotheksversionen durchaus unterscheiden können, ist diese Krümelkackerei tatsächlich von Belang: Mit einer älteren Ausgabe der Library lässt sich das Programm oft gar nicht oder nur unter großen Mühen kompilieren.
Die zweite Klammer in der Fehlermeldung teilt mit, welche Einzelheiten genau fehlen: Im Beispiel vermisst das configure-Skript headers and libraries, manchmal zeigt es aber auch das Fehlen einer einzelnen (Teil-)Bibliothek an, etwa library qt-mt.
Mit libraries sind die vorkompilierten Bibliotheksbinaries gemeint, gegen die das zu übersetzende Programm gelinkt werden muss, um lauffähig zu sein. Sie werden in der Regel in Verzeichnisse namens lib installiert. Im Spezialfall der library qt-mt fehlen nicht alle vom Qt-Paket bereitgestellten Shared Libraries, sondern nur eine spezielle, die Multithread-Ausgabe der Qt-Bibliothek.
headers hingegen meint die in Dateien mit der Endung .h abgelegten Beschreibungen der Programmierschnittstellen der Bibliothek. Sie werden in der Regel in einem Unterverzeichnis namens include abgelegt. Ohne sie lässt sich kein Quellcode kompilieren, denn dann sind die vom Programm benutzten Bibliotheksfunktionen dem Compiler schlicht unbekannt.
Wer eine Bibliothek selbst übersetzt, installiert in der Regel sowohl die Libraries, als auch die Header-Dateien. Fehlt qt-mt bei einer selbstkompilierten Qt-Bibliothek, darf das GUI-Toolkit noch einmal neu übersetzt werden, und zwar mit der configure-Option -thread, um die Multithread-Version zu bekommen.
Die meisten User installieren ihre Bibliotheken jedoch aus vorgefertigten Binär-Paketen. Fehlt eine Library, ist die Lösung einfach: Her mit dem entsprechenden Bibliothekspaket, zum Beispiel qt3.rpm bei SuSE 8.0. Andere Distributoren sind bei der Namensgebung ihrer Pakete freundlicher und geben wie beim Mandrake-RPM libqt3-3.0.5-2mdk.i586.rpm Versionsnummer (3.0.5), Patchlevel (2) und Ziel-Plattform (Intel-kompatible 586er) mit an.
Da die meisten etablierten Distributoren offensichtlich davon ausgehen, dass ihre User ohnehin nie selbst kompilieren, installieren sie oft zwar die Library, nicht aber die zugehörigen Headerfiles. Diese befinden sich in separat gehaltenen Paketen, die außer dem Bibliotheksnamen den Zusatz dev oder devel im Namen enthalten (z. B. libqt3-devel-3.0.5-2mdk.i586.rpm, qt3-devel.rpm oder qt-devel-3.0.5-7.11.i386.rpm). Der Name ist missverständlich: Es handelt sich eben nicht um Pakete, die ausschließlich für Programmierer gedacht sind, auch wenn sie sich im Installationstool der Distribution meist unter der Rubrik "development" (englisch für "Entwicklung") finden lassen.
Hat Ihr Distributor diesem Werkzeug keine Suchfunktion spendiert, greifen Sie zum Beispiel auf die des Paketmanagers KPackage zurück (Abbildung 1).
Sollte der Paketmanager beim Nachinstallieren aufgrund nicht aufgelöster Paketabhängigkeiten streiken, weitet sich die Installationsorgie selbstverständlich auf die fehlenden Programme und Bibliotheken aus. Erst danach kann man sich wieder der Kompilierung des Ursprungspakets zuwenden.
Alles da, nichts gefunden
Ich habe Qt 3.0.2 installiert, aber ./configure bricht trotzdem mit oben genannter Fehlermeldung ab. Wieso wird Qt nicht gefunden?
Dr. Linux: Überprüfen Sie die Variable QTDIR. Um älteren KDE-Programmen eine Chance zu geben, lassen es fast alle Distributionen zu, verschiedene Versionen der Qt-Bibliothek nebeneinander zu installieren. Kompiliert man Qt selbst, geht dies mit entsprechend gesetzter configure-Option --prefix=Zielverzeichnis ohnehin.
Zeigt QTDIR auf ein Verzeichnis, das eine Qt-2-Ausgabe enthält, …
perle@linux:~> echo $QTDIR /usr/lib/qt2/
… findet configure nur diese, nicht aber die ebenfalls installierte passende 3.0.er Version. Wichtig: Damit der echo-Befehl den Inhalt der Variablen ausgibt, muss dieser das $-Zeichen vorangestellt sein.
Um die Variable so zu ändern, dass sie auf das Verzeichnis mit der gesuchten Qt-Bibliothek zeigt, benutzen Sie den export-Befehl auf der Kommandozeile:
export QTDIR=/usr/lib/qt-3.0.2
Geben Sie als Argument das Verzeichnis an, in dem das lib- und das include-Subdirectory mit den Bibliotheks- und Header-Dateien in der passenden Version liegen. Bitte beachten Sie: Dieser export-Befehl bezieht sich nur auf die aktuelle Shell und Prozesse, die in ihr aufgerufen werden. In allen anderen Terminalfenstern gilt weiterhin der alte QTDIR-Wert.
Außer der richtigen Qt-Bibliothek muss configure bei KDE-Applikationen die jeweils passende Version der kdelibs (einschließlich der entsprechenden Header-Dateien) finden. Auch hier kann man wieder eine Variable bemühen: Ist KDEDIR gesetzt, gibt sie das Verzeichnis an, in dem die verwendete KDE-Version installiert ist. Auch deren Wert sehen Sie mit echo an und ändern ihn mit export.
Auf einigen Systemen ist zusätzlich die Variable KDEHOME gesetzt, diese lässt sich in gleicher Weise anpassen. Sie hat aber eine andere Funktion: KDEHOME enthält das Verzeichnis zur Speicherung der persönlichen KDE-Daten, etwa ~/.kde.



