qtforum.de

Guten Tag,

ich habe ein Problem mit einer dll, die ich mit Qt erstellt habe. Die dll besitzt keine GUI und deshalb keine QApplication.
Ich führe nun die dll mit einem anderem Programm aus und die dll funktioniert nicht, weil das Programm die Qt-Libs nicht findet. Erst wenn ich die benötigten Qt-dll's (Qtcore4.dll,QtGui4.dll ...) in den Ordner der Applikation kopiere, funktioniert meine dll.
Wie kann ich die Qt-Libs direkt in meine dll übernehmen, ohne sie in diesen Ordner kopieren zu müssen?

Foren-Suche 'statisch linken'
Aber was ist so schlimm die Dlls mitzuliefern?

ich wollte die notwendigen dll's alle in einen ordner schieben und dann während der laufzeit über einen festen pfad dynamisch laden.
Leider funktionierte der Funktionsaufruf in meiner dll nicht:

QApplication::addLibraryPath("./lib");

ich werde jetzt mal das library statisch erzeugen...

QApplication::addLibraryPath() hat rein gar nichts mit dynamisch gelinkten Libraries zu tun sondern nur mit Plugins...

Wichtig ist an der stelle das aktuelle ausführungsverzeichnis der ladenden anwendung (bei Qt geht das mit QDir::setCurrent()). Wenn deine DLL die Qt DLLs nicht statisch linkt, dann musst du vor dem laden der DLL das ausführungsverzeichnis auf den ordner mit den Qt DLLs setzen.
Dann sollte es gehen.

Ich kann nicht verstehen, warum immer statisches linken empfohlen wird. Es wurden ja nciht umsonst die dlls erfunden,

und bei Qt hat das noch den großen Nachteil, dass man dann sein Program auch unter der LGPL stellen muss, was die meisten stören dürfte, weil ja open source so doof ist ^^

und dann noch nichmal auf so etwas hinzuweißen, was soll den sowas?

bbt hat geschrieben:Ich kann nicht verstehen, warum immer statisches linken empfohlen wird.

Wo habe ich das empfohlen??

Christian81 hat geschrieben:

bbt hat geschrieben:Ich kann nicht verstehen, warum immer statisches linken empfohlen wird.

Wo habe ich das empfohlen??

Gut vll. nicht dirrekt empfohlen, aber ich finde man sollte trotzdem diesen großen Nachteil mit erwähnen, immer wenn man etwas von statisch linken schreibt, da man hier die Leute in ein offenes Messer rennen lässt.

Ich kann nicht verstehen, warum immer statisches linken empfohlen wird. Es wurden ja nciht umsonst die dlls erfunden

Naja, das Konzept der Dlls an sich ist nicht schlecht, nur hat M$ es vergessen (oder expliziet nicht getan), eine versionierungsystem für die Dlls vorzugeben !

Hasst du mal mit nem groesseren project zu tun, wo du Plugins mit grafischer oberflaeche (meist wird eh QT genommen) von fremdherstellern entwickelt werden, wo du keinen einfluss auf den compiler und die QT version nehmen kannst, dann ist statisches Linken (gegen die QT z.b.) das letzte Bollwerk gegen das absolute Programmierchaos.
Leider sind die QT libs nicht 100% binaer abwaertskombatibel, sondern nur codekombatibel ...

Ich kann den leuten da ned sagen:
Nehmt statt dem der 4.3.x QT, die 4.6.1 ... dann krieg ich sofort die Lizenzkosten fuer eine QT-Installation aufs Projekt gerechnet.
Oder die qt4libs mit dem gcc erzeugt kann ich ned anziehen, ich brauch VS2005/VS2008 ... boese Sache (fuer die Projectkosten).
(nee VS 2008 erzeugte App, die qt-dlls auch auf vs2008, und ein plugin bei was mitm gcc/mingw erzeugt wurde und dynamisch die qt libs anzieht, kann schon sehr sehr komisches verhalten und abstruse fehlermeldungen erzeugen )

Besser: Ich kann das zeugs so ned anziehen, ihr muesst das in die Dll integrieren (statisch linken). Das ist meist kein problem, weil es eben nicht in die Anschaffung neuer Software oder Lizenzen mündet. In dem Falle, sind die Vorteile der Dll nix im Vergleich zu dem Kosten/Chaos was sie anrichten koennen.

Aber prinzipiell hasst scho recht, wenn man alles selber unter kontrolle hat, sollt man die dlls auch nutzen.

Ciao ...

Im Prinzip wird bei jedem Programmstart erst einmal geprüft, ob die Bibliotheken mit den verwendeten Funktionen vorhanden sind, bevor überhaupt etwas vom eigentlichen Code ausgeführt wird. Fehlt etwas, kommt es erst garnicht zur Ausführung. Von daher hilft es nur, die DLLs an den richtigen Ort zu kopieren (Windows geht dabei nach der normalen Pfad-Variable, die auch für EXE-Dateien gilt) und es zu versuchen, zu vermeiden, dass zu viele DLLs gebraucht werden. Dynamisch linken hat bei kleineren Programmen immer den Nachteil, dass man die DLLs vollständig dazu packen muss - ob da eine oder hundert Funktionen von gebraucht werden. Im Falle von QT sind dass schnell mal 20MB für ein Programm mit 100KB Größe.

Willst du statisch linken, musst du erstmal QT neu kompilieren. Das dauert erstens ewig und zweitens gibt es Features, die man deaktivieren sollte, da sie beim statischen linken meist zum Crash führen (in der aktuellen Version z.B. Phonon).

Ich weiss garnicht, warum Nokia nicht einmal Hybrid-Distributionen herausgibt. Was ist da so schwer dran, die ganzen statischen Libs (.a-Dateien) noch hinzuzupacken und qmake so zu erweitern, dass man per Option sich aussuchen kann, ob ein Makefile für statisches oder dynamisches Linken erzeugt werden soll?

GoaSkin hat geschrieben: Ich weiss garnicht, warum Nokia nicht einmal Hybrid-Distributionen herausgibt. Was ist da so schwer dran, die ganzen statischen Libs (.a-Dateien) noch hinzuzupacken und qmake so zu erweitern, dass man per Option sich aussuchen kann, ob ein Makefile für statisches oder dynamisches Linken erzeugt werden soll?

Siehe Post von RHBaum - lizenztechnisch ein größeres Problem. Außerdem heissen die statischen und import-Libs gleich.