Qt für Linux/X11 - Einsatz

In dieser Dokumentation werden spezifische Fragen der Bereitstellung von Qt für Linux/X11 behandelt. Wir werden die Prozeduren anhand des Einsatzes der Plug & Paint-Beispielanwendung demonstrieren, die mit dem Qt-Quellpaket geliefert wird.

Aufgrund der Vielzahl von Unix-Systemen (wie kommerzielle Unixe, Linux-Distributionen usw.) ist der Einsatz unter Unix ein komplexes Thema. Bevor wir beginnen, sollten Sie sich darüber im Klaren sein, dass Programme, die für eine Unix-Variante kompiliert wurden, wahrscheinlich nicht auf einem anderen Unix-System laufen werden. Wenn Sie zum Beispiel keinen Cross-Compiler verwenden, können Sie Ihre Anwendung nicht auf Irix kompilieren und sie auf AIX verteilen.

Statisches Linken

Statisches Linken ist oft der sicherste und einfachste Weg, eine Anwendung unter Unix zu verteilen, da es Sie von der Aufgabe entbindet, die Qt-Bibliotheken zu verteilen und sicherzustellen, dass sie sich im Standardsuchpfad für Bibliotheken auf dem Zielsystem befinden.

Qt statisch bauen

Um diesen Ansatz zu verwenden, müssen Sie damit beginnen, eine _statische_ Version der Qt-Bibliotheken zu erstellen. Folgen Sie den Schritten in Qt für Linux/X11 - Erstellen vom Quellcode, aber denken Sie daran, ein -static Argument zur Konfiguration hinzuzufügen:

mkdir -p ~/dev/qt-build
cd ~/dev/qt-build
/tmp/qt-everywhere-src-6.8.2/configure -static

Linken der Anwendung mit der statischen Version von Qt

Sobald Qt statisch gebaut ist, besteht der nächste Schritt darin, das Makefile zu regenerieren und die Anwendung neu zu erstellen. Zuerst müssen wir in das Verzeichnis wechseln, das die Anwendung enthält:

cd /path/to/Qt/examples/widgets/tools/plugandpaint/app

Führen Sie nun qmake aus, um ein neues Makefile für die Anwendung zu erstellen, und führen Sie einen sauberen Build durch, um die statisch gelinkte ausführbare Datei zu erzeugen:

make clean
PATH=/path/to/Qt/bin:$PATH
export PATH
qmake -config release
make

Wahrscheinlich wollen Sie gegen die Release-Bibliotheken linken, und Sie können dies beim Aufruf von qmake angeben. Beachten Sie, dass wir den Pfad zu dem statischen Qt, das wir gerade gebaut haben, angeben müssen.

Um zu überprüfen, ob die Anwendung wirklich statisch mit Qt gelinkt ist, führen Sie das Tool ldd aus (auf den meisten Unices verfügbar):

ldd ./application

Stellen Sie sicher, dass die Qt-Bibliotheken in der Ausgabe nicht erwähnt werden.

Vorausgesetzt, dass alles fehlerfrei kompiliert und gelinkt wurde, sollten wir nun eine plugandpaint Datei haben, die bereit für den Einsatz ist. Eine einfache Möglichkeit zu überprüfen, ob die Anwendung wirklich eigenständig ausgeführt werden kann, besteht darin, sie auf einen Rechner zu kopieren, auf dem weder Qt noch andere Qt-Anwendungen installiert sind, und sie auf diesem Rechner auszuführen.

Denken Sie daran, dass, wenn Ihre Anwendung von compilerspezifischen Bibliotheken abhängt, diese trotzdem zusammen mit Ihrer Anwendung weiterverteilt werden müssen. Weitere Informationen finden Sie im Abschnitt Anwendungsabhängigkeiten.

Das Plug & Paint Beispiel besteht aus mehreren Komponenten: Die Kernanwendung(Plug & Paint) und die Plugins Basic Tools und Extra Filters. Da wir Plugins nicht mit dem statischen Linking-Ansatz bereitstellen können, ist die von uns bisher vorbereitete ausführbare Datei unvollständig. Die Anwendung wird zwar ausgeführt, aber die Funktionalität ist aufgrund der fehlenden Plugins deaktiviert. Um Plugin-basierte Anwendungen bereitzustellen, sollten wir den Shared-Library-Ansatz verwenden.

Gemeinsam genutzte Bibliotheken

Bei der Bereitstellung der Anwendung plugandpaint mit dem Shared-Libraries-Ansatz gibt es zwei Herausforderungen: Die Qt-Laufzeitumgebung muss zusammen mit der ausführbaren Datei der Anwendung korrekt verteilt werden, und die Plugins müssen an der richtigen Stelle auf dem Zielsystem installiert werden, damit die Anwendung sie finden kann.

Qt als Shared Library bauen

Wir gehen davon aus, dass Sie Qt bereits als Shared Library installiert haben, was bei der Installation von Qt standardmäßig der Fall ist, und zwar im Verzeichnis /path/to/Qt.

Verknüpfen der Anwendung mit Qt als Shared Library

Nachdem wir sichergestellt haben, dass Qt als Shared Library installiert ist, können wir die Anwendung plugandpaint erstellen. Zuerst müssen wir in das Verzeichnis wechseln, das die Anwendung enthält:

cd /path/to/Qt/examples/tools/plugandpaint

Führen Sie nun qmake aus, um ein neues Makefile für die Anwendung zu erstellen, und führen Sie einen sauberen Build durch, um die dynamisch gelinkte ausführbare Datei zu erstellen:

make clean
qmake -config release
make

Dies baut die Kernanwendung, die folgenden Schritte werden die Plugins bauen:

cd ../plugandpaint/plugins
make clean
qmake -config release
make

Wenn alles ohne Fehler kompiliert und gelinkt wurde, erhalten wir eine ausführbare Datei plugandpaint und die Plugin-Dateien libpnp_basictools.so und libpnp_extrafilters.so.

Erstellen des Anwendungspakets

Unter Unix gibt es keine Standard-Paketverwaltung, daher ist die unten vorgestellte Methode eine generische Lösung. Lesen Sie in der Dokumentation Ihres Zielsystems nach, wie Sie ein Paket erstellen können.

Um die Anwendung bereitzustellen, müssen wir sicherstellen, dass wir die relevanten Qt-Bibliotheken (entsprechend den in der Anwendung verwendeten Qt-Modulen), das Plattform-Plugin und die ausführbare Datei in denselben Verzeichnisbaum kopieren. Denken Sie daran, dass, wenn Ihre Anwendung von compilerspezifischen Bibliotheken abhängt, diese ebenfalls zusammen mit Ihrer Anwendung weiterverteilt werden müssen. Weitere Informationen finden Sie im Abschnitt Abhängigkeiten von Anwendungen.

Wir werden die Plugins in Kürze behandeln, aber das Hauptproblem bei gemeinsam genutzten Bibliotheken ist, dass Sie sicherstellen müssen, dass der dynamische Linker die Qt-Bibliotheken findet. Wenn nicht anders angegeben, durchsucht der dynamische Linker nicht das Verzeichnis, in dem sich Ihre Anwendung befindet. Es gibt viele Möglichkeiten, dieses Problem zu lösen:

• Sie können die Qt-Bibliotheken in einem der Systembibliothekspfade installieren (z.B. /usr/lib auf den meisten Systemen).
• Sie können beim Linken der Anwendung einen vorgegebenen Pfad an die Kommandozeilenoption -rpath übergeben. Dadurch wird der dynamische Linker angewiesen, beim Starten Ihrer Anwendung in diesem Verzeichnis zu suchen.
• Sie können ein Startskript für Ihre Anwendung schreiben, in dem Sie die Konfiguration des dynamischen Linkers ändern (z. B. indem Sie das Verzeichnis Ihrer Anwendung zur Umgebungsvariablen LD_LIBRARY_PATH hinzufügen).

  Hinweis: Wenn Ihre Anwendung mit der Option "Setze Benutzer-ID bei Ausführung" ausgeführt wird und wenn sie root gehört, wird LD_LIBRARY_PATH auf einigen Plattformen ignoriert. In diesem Fall ist die Verwendung des LD_LIBRARY_PATH-Ansatzes keine Option).

Der Nachteil des ersten Ansatzes ist, dass der Benutzer über Superuser-Rechte verfügen muss. Der Nachteil des zweiten Ansatzes besteht darin, dass der Benutzer möglicherweise keine Berechtigung hat, in den vorgegebenen Pfad zu installieren. In beiden Fällen haben die Benutzer nicht die Möglichkeit, in ihr Heimatverzeichnis zu installieren. Wir empfehlen den dritten Ansatz, da er am flexibelsten ist. Ein Skript plugandpaint.sh sieht zum Beispiel so aus:

#!/bin/sh
appname=`basename $0 | sed s,\.sh$,,`

dirname=`dirname $0`
tmp="${dirname#?}"

if [ "${dirname%$tmp}" != "/" ]; then
dirname=$PWD/$dirname
fi
LD_LIBRARY_PATH=$dirname
export LD_LIBRARY_PATH
$dirname/$appname "$@"

Wenn Sie dieses Skript anstelle der ausführbaren Datei ausführen, sind Sie sicher, dass die Qt-Bibliotheken vom dynamischen Linker gefunden werden. Beachten Sie, dass Sie das Skript nur umbenennen müssen, um es mit anderen Anwendungen zu verwenden.

Bei der Suche nach Plugins sucht die Anwendung in einem Plugins-Unterverzeichnis innerhalb des Verzeichnisses der ausführbaren Anwendung. Entweder müssen Sie die Plugins manuell in das Verzeichnis plugins kopieren, oder Sie können die DESTDIR in den Projektdateien der Plugins einstellen:

DESTDIR = /path/to/Qt/plugandpaint/plugins

Ein Archiv, das alle Qt-Bibliotheken und alle Plugins enthält, die für die Ausführung der Anwendung plugandpaint erforderlich sind, müsste die folgenden Dateien enthalten:

Auf den meisten Systemen ist die Erweiterung für gemeinsame Bibliotheken .so. Eine bemerkenswerte Ausnahme ist HP-UX, das .sl verwendet.

Denken Sie daran, dass, wenn Ihre Anwendung von compilerspezifischen Bibliotheken abhängt, diese trotzdem zusammen mit Ihrer Anwendung weitergegeben werden müssen. Weitere Informationen finden Sie im Abschnitt Anwendungsabhängigkeiten.

Um zu überprüfen, ob die Anwendung nun erfolgreich bereitgestellt werden kann, können Sie dieses Archiv auf einem Rechner ohne Qt und ohne installierten Compiler entpacken und versuchen, es auszuführen, d. h. das Skript plugandpaint.sh ausführen.

Eine Alternative zum Ablegen der Plugins im Unterverzeichnis plugins ist das Hinzufügen eines benutzerdefinierten Suchpfades, wenn Sie Ihre Anwendung mit QApplication::addLibraryPath() oder QApplication::setLibraryPaths() starten.

QCoreApplication::addLibraryPath("/some/other/path");

Abhängigkeiten der Anwendung

Zusätzliche Bibliotheken

Um herauszufinden, von welchen Bibliotheken Ihre Anwendung abhängt, führen Sie das Tool ldd aus (auf den meisten Unices verfügbar):

ldd ./application

Es listet alle gemeinsam genutzten Bibliotheken auf, von denen Ihre Anwendung abhängt. Je nach Konfiguration müssen diese Bibliotheken zusammen mit Ihrer Anwendung weiterverteilt werden. Insbesondere die C++-Standardbibliothek muss neu verteilt werden, wenn Sie Ihre Anwendung mit einem Compiler kompilieren, der binär nicht mit dem Systemcompiler kompatibel ist. Wenn möglich, ist es die sicherste Lösung, statisch gegen diese Bibliotheken zu linken.

Sie werden wahrscheinlich dynamisch mit den regulären X11-Bibliotheken linken wollen, da einige Implementierungen versuchen werden, andere gemeinsam genutzte Bibliotheken mit dlopen() zu öffnen, und wenn dies fehlschlägt, könnte die X11-Bibliothek Ihre Anwendung zum Absturz bringen.

Es ist auch erwähnenswert, dass Qt nach bestimmten X11-Erweiterungen, wie Xinerama und Xrandr, sucht und sie möglicherweise einbindet, einschließlich aller Bibliotheken, gegen die sie linken. Wenn Sie nicht garantieren können, dass eine bestimmte Erweiterung vorhanden ist, ist es am sichersten, sie bei der Konfiguration von Qt zu deaktivieren (z.B. ./configure -no-xrandr).

FontConfig und FreeType sind weitere Beispiele für Bibliotheken, die nicht immer zur Verfügung stehen oder nicht immer binärkompatibel sind. So seltsam es auch klingen mag, einige Softwarehersteller hatten Erfolg, indem sie ihre Software auf sehr alten Rechnern kompiliert haben und sehr vorsichtig waren, die darauf laufende Software nicht zu aktualisieren.

Wenn Sie Ihre Anwendung gegen die statischen Qt-Bibliotheken linken, müssen Sie explizit mit den oben erwähnten abhängigen Bibliotheken linken. Dazu fügen Sie sie der Variable LIBS in Ihrer Projektdatei hinzu.

Qt-Plugins

Alle Qt GUI Anwendungen benötigen ein Plugin, das die Qt Platform Abstraction (QPA) Schicht in Qt implementiert. Für Linux/X11 lautet der Name des Plattform-Plugins libqxcb.so. Diese Datei muss sich in einem bestimmten Unterverzeichnis (standardmäßig platforms) unter Ihrem Distributionsverzeichnis befinden. Alternativ ist es möglich, den Suchpfad anzupassen, den Qt verwendet, um seine Plugins zu finden, wie unten beschrieben.

Ihre Anwendung kann auch von einem oder mehreren Qt-Plugins abhängen, wie z.B. dem JPEG-Bildformat-Plugin oder einem SQL-Treiber-Plugin. Vergewissern Sie sich, dass Sie alle Qt-Plugins, die Sie benötigen, mit Ihrer Anwendung verteilen. Ähnlich wie beim Plattform-Plugin muss sich jedes Plugin in einem bestimmten Unterverzeichnis (z.B. imageformats oder sqldrivers) in Ihrem Distributionsverzeichnis befinden.

Der Suchpfad für Qt-Plugins (sowie einige andere Pfade) ist in der Bibliothek QtCore fest einprogrammiert. Standardmäßig ist der erste Plugin-Suchpfad als /path/to/Qt/plugins fest programmiert. Wie bereits erwähnt, hat die Verwendung vorgegebener Pfade gewisse Nachteile, so dass Sie verschiedene Alternativen prüfen müssen, um sicherzustellen, dass die Qt-Plugins gefunden werden:

• Die Verwendung von qt.conf. Dies ist der empfohlene Ansatz, da er die größte Flexibilität bietet.
• Verwendung von QApplication::addLibraryPath() oder QApplication::setLibraryPaths().
• Verwendung eines Installationsprogramms eines Drittanbieters oder des Paketmanagers des Zielsystems, um die fest kodierten Pfade in der Bibliothek QtCore zu ändern.

Das Dokument How to Create Qt Plugins (Wie man Qt-Plugins erstellt ) umreißt die Punkte, auf die Sie bei der Erstellung und Bereitstellung von Plugins für Qt-Anwendungen achten müssen.