qtforum.de

Hallo ich bins wieder mal ,

wenn ich eine release exe mit qt creator erstelle, brauch er mindestens immer die qtgui4.dll und die qtcore4.dll.

Jetzt möchte ich die dass er beim asuführen der exe, die dlls in "current-exe-pfad"/bin sucht.

d.h ich will meine dlls in /bin ablegen.

Leider bin ich gerade etwas doof und finde keine möglichkeit dies zu realisieren.


Merci wiederma im Voraus

bitte verscheiben falls im falschen thread... danke

Sowas geht nicht, liegt aber am Betriebssystem.

ah oke danke fuer die Info.


Kann ich die 2 dll´s direkt mit in die exe kompilieren ?
ist die exe halt groesser aber wuerde mich nicht stoeren.


gruss aenni

--> Foren-Suche 'statisch linken'

danke fuer die Hilfe !

Sowas geht nicht, liegt aber am Betriebssystem.

Naja, das ist aber nur die halbe Wahrheit

dll's werden bei windows standardmaessig (Ohne Pfadangabe bei loadlibrary) an folgenden Stellen gesucht:
- "Startverzeichniss" des Prozesses, also das woraus die exe ausgerufen wuerde
- Alles was im Suchpfad steht (PATH Enviroment)
- Systemverzeichnisse

Das bloede iss nur, das man mit Eintraegen in der Registry Punkt 2 global unterbinden kann. Macht aber kaum einer !!!

Das 2.te Bloede ist ... Du kannst die Path Variable in deinem Prozess modifizieren, das ist kein Problem. Aber zum Laden der qt libs muesstest du das vorm Anziehen selbiger in den Importlibs machen. Und das ist der Haken ... die main wird erst nach den initialisierungscode der Bibs ausgefuehrt, wenn die zugelinkt werden.
Es gibt möglichkeiten das hinzubekommen, aber da greift man zu tief in compiler / linker probleme etc ein als dass sich das lohnt.
es gibt aber einfachere "Tricks". ne simple Starter-exe die die Umgebung korrekt setzt, und dann ueber QProcess die eigentliche Qt App laed ... z.B.

mit statisch gebunden QT-Libs machst du dein Programm ziemlich robust gegen Qt Versionsprobleme etc. Auf der anderen Seite untergraebst Du das dll Prinzip von M$ ...
QT dlls sind aber auch keine unproblematischen System-Dlls die vorgesehene Schnittstellenarten verwenden (QT ist c++ statt c ) und auch nicht unbedingt M$ Kompatiblitaets-Richtlinien befolgen ...
von daher find ich es schon gerechtfertigt, die QT lieber statisch zu binden .... grad bei "kleineren" tools. wenn noch die runtime statisch linkst, kriegst schoene fette (wem intressieren heut noch 20-30 MB) binaries die aber dafuer auf jedem windows system laufen wo sie die entsprechenden windows dlls finden (kernel.dll gui.dll etc) also bei faktisch allen ....

Ciao ...

Naja so gross sind die statisch gelinkten Dateien nun auch wieder nicht - ohne Gui geht unter 1MB schon was, mit Gui ab ~3 (jeweils mit upx gepackt)

Klar, packen vermindert das "Transportproblem", aber kritischer seh ich zumindest die Groesse beim Programm-Start Naja zumindest früher war es mal das "Problem" das groessere Binaries halt spuerbar längere ladezeiten hatten (und man intern mit groesseren, langsameren Speichermodellen arbeiten musste ). Heutzutage kein Thema mehr. Also bei 20 MiB Binaries (qtcore, qtgui, qtxml) krieg ich halt kein schlechtes Gewissen mehr !
Und die 20 MiB beim Verteilen, also wo man heutzutage Powerpointpraesentationen und "Hilfen" in HD-Videostreams verpackt, weil der Vorfueher keine Zeit mehr hat bei ner Besprechung den "Nachste Seite" Button zu druecken ....

Ciao ...

Note to myself: Projekt-Manager fragen, was mein Antrag auf Speichererweiterung von 2 auf 4 GB macht ^^