Plugin-Verzeichnis

[Willi2793]

Hallo,

ich weiß das viele bei dem Thema die augen verdrehen. Und ich habe wirklich jetzt lange gesucht und probiert bevor ich mich an Euch wende.

Folgendes: ich habe unter Windows ein programm erstellt das auf eine MySQL-Datenbank per ODBC zugreifen soll. Das funktioniert auf dem Entwicklungsrechner auch völlig problemlos.

Nun will ich aber das Programm auf einem Rechner ausführen der keine installierte QT-Umgebung hat. Ich habe also alle DLLs kopiert und dieses Verzeichnis in den Pfad aufgenommen. Das ODBC-Plugin habe ich nun in die Verzeichnisse:

- application-dir/plugins/sqldrivers/
- application-dir/sqldrivers/
- dll im pfad/plugins/
- dll im pfad/plugins/sqldrivers/

kopiert und auch auf alle diese Verzeichnisse per im Application-Verzeichnis liegender qt.conf verwiesen. Das natürlich alles in verschiedenen nacheinander erfolgenden Versuchen. Alle Versuche ohne Erfolg.

Aufgrund eines alten Artikels hier im Forum habe ich dann das Plugin in ein Verzeichnis kopiert das exakt so heisst wie auf meinem Entwicklungsrechner. Dann, und nur dann, funktioniert das Programm.

Daraufhin habe ich die DLLs mal durchsucht und habe in der QtCore4.dll gefunden das die Variable "qt_plugpath" auf eben diesen Pfad gesetzt wird. Hardcodiert. Wie kann ich dies denn nun ändern? Möglichst von "aussen" also ohne QT oder das Programm explizit für den Zielrechner zu bauen?

Grüße,
Willi

[Christian81]

sqlplugins gehören (wie die Doku so schön schreibt ...) unter <executable-path>/sqldrivers. eine qt.conf ist nicht nötig. Und wenn das Plugin dort nicht geladen wird -> Dependency Walker und schauen was HKEY_CURRENT_USER\Software\Trolltech\OrganizationDefaults so alles zu dem Plugin sagt.

[Willi2793]

Ja, das habe ich alles gecheckt. Auch in dem Verzeichnis das Du anmerkst hatte ich es. Aber es wird erst geladen wenn es wirklich aus dem exakt gleichlautenden Verzeichnis wie auf dem Entwicklungsrechner geladen werden kann.

[Christian81]

Und was sagt nun der Registry-Key???

[Willi2793]

Nichts. Es war der Pfad eingetragen der wie auf dem Entwicklungsrechner heißt. Ich habe das Verzeichnis und auch den Registry-Key gelöscht. Das Programm lief nicht und ind er Registry änderte sich Nichts. Dann habe ich das Verzeichnis wieder so angelegt und das Programm lief und der Registry-Key wurde wieder so eingtragen.

[Christian81]

Wenn es unter dem Executable-Pfad ein Verzeichnis sqldrivers gibt und darin dlls sind dann tauchen die auch in der Registry auf...

[Willi2793]

Und genau das tun sie eben nicht. Das ist ja eben das Problem.

[Christian81]

Das glaube ich nicht - bis jetzt hat sich so etwas immer als Layer8-Problem beim Anwender herausgestellt. ggf. gibt es noch andere Qt-Dlls im PATH auf de Zielrechner oder ähnliches. Hier mal wieder der Hinweis auf Dependency Walker.
/Edit: Und wenn Du ein kleines, kompiliertes Beispiel irgendwo hochladen kannst könnten wir es bei uns auch mal ausführen und schauen ob wirklich nichts in die Registry eingetragen wird.

[Willi2793]

Das glaube ich nicht

Das kann ich nachvollziehen.

Der Dependency Walker zeigt keine fehlenden Abhängigkeiten. Den Pfad werde ich nachher nochmal durchsuchen (mit wenig Hoffnung).

Das Mini-Beispiel wird wenig bringen. Das Problem ist ja nicht das Anwendungs-Programm sondern das QT die Plugins nicht lädt sondern nur ganz dediziert an einer ganz bestimmten Stele sucht. Aber auch das werde ich noch erstellen. Aber das wird aus Zeitgründen auch noch etwas dauern.

[Willi2793]

So, den Pfad habe ich durchsucht. Keinen Fund.

[Willi2793]

So, ich habe jetzt QT neu gebaut. Vorher hatte ich als condigure-Parameter (den SQL-Teil betreffend):

Code: Alles auswählen

-plugin-sql-sqlite -plugin-sql-odbc

nun habe ich

Code: Alles auswählen

-qt-sql-sqlite -qt-sql-odbc

Damit werden die plugins gar nicht mehr gebraucht. Und damit kann ich leben.

[Eltharion]

Auch wenn das ein alter Beitrag ist, die Frage ist noch aktuell und wird immer wieder mal gestellt, daher will ich sie beantworten. Vielleicht sucht ja mal wer danach...

In der Qt5Core.dll stehen die Pfade zum prefix (QTDIR), zu den docs, translations, libs und auch den plugins fest vorgegeben drin. Es ist fraglich, ob solche Pfade überhaupt so hart eingebaut benötigt werden, aber wenn falsche Werte dort stehen, weil die Dateien verschoben wurden, dann kann es durchaus passieren, dass es deshalb Probleme gibt.

Im o.g. Fall kann das verifiziert werden, indem das Plugins-Verzeichnis an die gleiche Stelle kopiert wird, wie auf dem Build-Rechner auch. Läuft dann alles, dann ist die Ursache klar. Wenn bspw. eine Fehlermeldung kommt, dass plugins/plattforms/qwindows.dll nicht geladen werden konnte, dann heißt das, dass das plugins-Verzeichnis nicht gefunden wurde. Aber Vorsicht, die Meldung kann auch kommen, wenn es zu viele Verzeichnisse gibt (z.B. Entwicklerverzeichnisse und die kopierten DLLs unter appdir/plugins noch mal). Dann steht in der zweiten Zeile (Liste gefundener Plattformen) sogar "windows" mit drin und trotzdem klappt das Laden ggf. nicht...

Lösungen:

Im mingwbuilds-projekt auf Sourceforge wird ein qtbinpatcher (http://www.tver-soft.org) mitgeliefert, um die hart eingebauten Pfade anzupassen. Es funktioniert, aber ich bin kein Freund davon.

Im Pfad der ausführbaren Datei eine Datei qt.conf ablegen und dort die Pfade zu Plugins oder Translations eintragen. Das hat der Fragesteller getan und ich eben auch. Mit der Angabe von c:\test als prefix und c:\test\plugins als plugins-Verzeichnis hat es nicht geklappt. Es musste c:/test heißen. Vielleicht lag es daran, dass das Durchprobieren der Verzeichnisse nicht half. Es ist möglich, auch relative Verzeichnisse anzugeben, also bspw.:

Code: Alles auswählen

[Paths]
Prefix = ..
Binaries = .
Plugins = plugins

für eine solche Struktur:

Code: Alles auswählen

app
  bin
    app.exe, auch die Qt-DLLs gehören dann hier her
  plugins
    plattforms
    ...

Es ist auch möglich, per Kommandozeilenparameter das Plugins-Verzeichnis anzugeben, aber das ist mehr für Testzwecke geeignet.

Oder man setzt die Verzeichnisse in der Anwendung (addLibraryPath()/setLibraryPaths())

Code: Alles auswählen

QApplication::addLibraryPath( QApplication::applicationDirPath() + QDir::separator() + ".." + QDir::separator() + "plugins");

Auf jeden Fall sollte man in einem solchen Fall daran denken, dass die Pfade alle auch fest in Qt eingebaut sind.

E*

[Christian81]

Die hart codierten Pfade sind auch schon in Qt4 drin, hat aber nichts mit der normalen Lösung wie in der Doku beschrieben zu tun.

[Eltharion]

Hallo Christian,

Lesen in der Doku reicht bei diesem Fehler nicht immer. Das Wissen über hardkodierte Pfade wird dann wichtig, wenn man aus dem Qt-Verzeichnis DLLs in eigene Verzeichnisse kopiert und damit Plugins und Qt-DLLs doppelt vorliegen. Und das ist bei der Softwareerstellung durchaus eine gängige Praxis um alles beieinander zu haben oder portable Versionen zu erstellen...

Du hast Recht, man braucht keine qt.conf und eigentlich finde ich, braucht man auch keine Registry-Keys. In der Regel funktioniert ja alles. Aber die Fragen im Forum betreffen Fälle, wo eben nicht alles funktioniert. Bei mir war bspw. die Ursache, dass ich eine 32 und eine 64-bit qt/mingw-Umgebung unter dem gleichen Namen benutzt hatte und dachte, die exe sucht sich ihre DLLs schon im jeweils richtigen Verzeichnis. Aber da hatte ich nicht mit der eingebauten Intelligenz der hardkodierten Plugin-Pfade gerechnet, die eben nicht das exe-Verzeichnis und auch nicht den mit addLibraryPath vorgegebenen Weg gut fanden, sondern schlicht zuerst auf c:\mingw/c:\qt zugriffen, dort sogar DLLs fanden, aber durcheinander kamen und die exe ohne Fehlermeldung abstürzen ließen. Um solchen Dingen aus dem Weg zu gehen habe ich dann doch die qt.conf als zweiten Hinweis auf das korrekte Verzeichnis eingeführt. Jeweils eine für 32 und 64 Bit. Damit stelle ich nur sicher, dass alles klappt. Obwohl in 99,9% aller Fälle es auch ohne qt.conf funktionieren wird.

In der Doku könnte man durchaus etwas darauf eingehen und die Vorrangmechanismen und mögliche Fehler erläutern. Und Projekte wie der qtbinpatcher (der m.E. keine zwingende Notwendigkeit ist) zeigen ja, dass es nicht einfach ist, immer alles korrekt einzurichten und das nicht alles immer von alleine läuft...

E*