Seite 1 von 1
Probleme mit DLLs, die QT benutzen
Verfasst: 26. Januar 2007 04:06
von Takki
Ich habe gerade folgendes, sehr merkwürdiges und schon kritisches Problem. Eines meiner Programme setzt sich aus einigen DLLs sowie einer Hauptexe zusammen, welche alle QT (dynamisch gelinkt) benutzen. Das Problem ist nun folgendes:
Sobald ich auch nur auf irgendetwas aus einer DLLs zugreifen möchte (z.B. ein exportierter QString), crasht das Ganze einfach (QtCore4.dll in diesem Fall). Oder will ich eine Instanz einer Klasse, die von QObject abgeleitet ist, erstellen, passiert das gleiche (erstelle ich eine "normale" Klasse, passiert nichts, also liegt es wohl eher nicht an meinem Code). Nun bin ich ziemlich ratlos... was mich am meisten wundert, im Debug-Build funktioniert es, nur im Release nicht (naja, ist ja oft so
). Also scheint es an den Release-DLLs von QT zu liegen (liegt zumindest nahe).
Kennt jemand das Problem? Wir benutzen übrigens QT 4.1.1 (ja es ist älter, aber meine Firma will nicht updaten...). Für jede Hilfe wäre ich äußert dankbar, da mir selber nichts mehr einfällt.
Gruß,
Daniel
Verfasst: 26. Januar 2007 06:34
von Christian81
Man kann (mit msvc) keine Debug und Release-Dlls mischen -> D.h. wenn man eine Debug-Executable baut, muss man gegen QtCored4.lib linken, bei Release gegen QtCore4.lib. Wenn man ein ordentliches Buildttool (qmake, cmake) benutzt wird das automatisch gemacht.
Verfasst: 26. Januar 2007 17:12
von Takki
Das ist mir schon klar, und die Libs sind auch richtig gesetzt. Also muss das Problem woanders liegen. Im Debug-Build benutzt er halt die qt*d.lib's und im Release-Build die Nicht-Debug-Varianten.
Verfasst: 26. Januar 2007 17:15
von Christian81
Ein anderes Problem ist mir nicht bekannt. Ich würde ggf. mal ein Release-Build mit Debug-Informationen erstellen und etwas debuggen. Ist Qt ggf. mit stl, exceptions (oder eben ohne) kompiliert worden, das PRgoramm aber mit anderen Optionen?
Verfasst: 26. Januar 2007 17:37
von Takki
Das mit den Debug-Infos habe ich ausprobiert, und da sieht man letztendlich nur, dass das Problem in der QtCore4.dll sitzt, also kommt man da nicht wirklich weiter.
Wie genau Qt compiliert wurde kann ich nicht sagen, da ich das nicht übernommen habe. Ich denke aber mal, dass nur Standardoptionen benutzt wurden bzw. wie ich meine Firma kenne wurden die vorcompilierten Sachen genommen. Wie genau sehen dort die Optionen aus?
Achja. Das Programm bestand vorher nur aus einer Exe, und da lief alles problemlos. Nur seit der Auslagerung mancher Teile in Dlls funktioniert es nicht mehr.
Verfasst: 26. Januar 2007 18:09
von Christian81
Takki hat geschrieben:Das mit den Debug-Infos habe ich ausprobiert, und da sieht man letztendlich nur, dass das Problem in der QtCore4.dll sitzt, also kommt man da nicht wirklich weiter.
Natürlich auch die Qt-Dlls mit debug-Infos kopilieren
Wie genau Qt compiliert wurde kann ich nicht sagen, da ich das nicht übernommen habe. Ich denke aber mal, dass nur Standardoptionen benutzt wurden bzw. wie ich meine Firma kenne wurden die vorcompilierten Sachen genommen. Wie genau sehen dort die Optionen aus?
siehe qt-4/mkspecs/win32-msvc2005 und qt-4-install/.qmake.conf
Achja. Das Programm bestand vorher nur aus einer Exe, und da lief alles problemlos. Nur seit der Auslagerung mancher Teile in Dlls funktioniert es nicht mehr.
Kannst Du daraus ggf. ein Testcase bauen?
Christian
Verfasst: 26. Januar 2007 19:44
von Takki
Qt-Dlls erstellen... hat noch nie wirklich funktioniert. Deswegen habe ich mich damit erst gar nicht weiter rumgeplagt.
Naja jetzt ein anderes Problem. Beim Linken der Release-Version gibt es folgende Fehler, die ich auch nicht wirklich nachvollziehen kann:
Code: Alles auswählen
Error 1 error LNK2019: unresolved external symbol "__declspec(dllimport) private: __thiscall QObject::QObject(class QObject const &)" (__imp_??0QObject@@AAE@ABV0@@Z) referenced in function "public: __thiscall uApp::UOrpaApplication::UOrpaApplication(class uApp::UOrpaApplication const &)" (??0UOrpaApplication@uApp@@QAE@ABV01@@Z) OrpaMain.obj
Error 2 error LNK2001: unresolved external symbol "__declspec(dllimport) private: __thiscall QObject::QObject(class QObject const &)" (__imp_??0QObject@@AAE@ABV0@@Z) UOrpaApplication.obj
Error 3 error LNK2001: unresolved external symbol "__declspec(dllimport) private: __thiscall QObject::QObject(class QObject const &)" (__imp_??0QObject@@AAE@ABV0@@Z) UOrpaCore.obj
Error 4 error LNK2001: unresolved external symbol "__declspec(dllimport) private: __thiscall QObject::QObject(class QObject const &)" (__imp_??0QObject@@AAE@ABV0@@Z) moc_UOrpaApplication.obj
Error 5 error LNK2019: unresolved external symbol "__declspec(dllimport) private: class QObject & __thiscall QObject::operator=(class QObject const &)" (__imp_??4QObject@@AAEAAV0@ABV0@@Z) referenced in function "public: class uApp::UOrpaApplication & __thiscall uApp::UOrpaApplication::operator=(class uApp::UOrpaApplication const &)" (??4UOrpaApplication@uApp@@QAEAAV01@ABV01@@Z) OrpaMain.obj
Error 6 error LNK2001: unresolved external symbol "__declspec(dllimport) private: class QObject & __thiscall QObject::operator=(class QObject const &)" (__imp_??4QObject@@AAEAAV0@ABV0@@Z) UOrpaApplication.obj
Error 7 error LNK2001: unresolved external symbol "__declspec(dllimport) private: class QObject & __thiscall QObject::operator=(class QObject const &)" (__imp_??4QObject@@AAEAAV0@ABV0@@Z) UOrpaCore.obj
Error 8 error LNK2001: unresolved external symbol "__declspec(dllimport) private: class QObject & __thiscall QObject::operator=(class QObject const &)" (__imp_??4QObject@@AAEAAV0@ABV0@@Z) moc_UOrpaApplication.obj
Zur Info: UOrpaApplication ist abgeleitet von QCoreApplication. In der Debug-Version funktioniert das natürlich. Kann es vielleicht sein, dass das Compilat der Release-Dlls von Qt einfach "schrott" ist? Irgendwo ist das alles Murks was mit den Release-Dlls abgeht, wenn man mich fragt.
Wenn das Compilieren der Dlls doch nur ginge... aber ein einfaches configure mit anschließendem nmake bringt Fehler (wo genau weiß ich jetzt nicht, aber es klappt zumindest nicht). Gibt es da irgendwo eine vernünftige Anleitung zu? In der Readme von Qt steht ja letzten Endes so gut wie nichts...
Verfasst: 26. Januar 2007 19:58
von Christian81
Also normalerweise sollte Qt recht einfach zu erstellen sein - ich habe leider nur eine Anleitung für die OpenSource - Version (da muss man noch ein wenig patchen bis man es mit msvc2005 kompilieren kann -> qtnode.net)
Normalerweise reicht ein 'configure --deineOptionen' mi VisualStudio Command Prompt (nicht cmd.exe! Dort sind einige Umgebungsvariablen nicht gesetzt) und warten. Als Optionen braucht man im Grunde nichts anzugeben. Dann werden automatisch die Debug und Release-DLLs erstellt.
Verfasst: 26. Januar 2007 20:14
von Takki
Naja ich werde wohl mal versuchen, Qt selber zu compilieren. Denn so komme ich nicht weiter, und das ist sehr unpraktisch
Danke erstmal soweit für deine Hilfe, mal sehen was mir noch so alles einfällt.
Verfasst: 26. Januar 2007 20:24
von Christian81
Was mir noch so einfällt - kann es sein dass die precompiled Binaries für einen anderen MSVC kompiliert wurden als ihr jetzt benutzt?
Naja egal- kompilier erstmal Qt selbst
Verfasst: 26. Januar 2007 21:18
von Takki
Also das Compilieren ging scheinbar... zumindest die wichtigen Teile von Qt, das Ax Zeug scheinbar nicht, aber gut. Nur gebracht hat das leider auch nichts. Die Linker-Fehler sind immernoch die selbigen. Mal mit statischen Libs versuchen, ansonsten bin ich ratlos.
Verfasst: 26. Januar 2007 22:04
von Takki
Ok also statische Libs von Qt erstellen bringt ca. 300 Linker-Fehler in meinem Projekt... also keine gute Idee. Also so langsam weiß ich keinen Rat mehr.
Verfasst: 26. Januar 2007 23:47
von Christian81
Nochmal: Erstelle ein kleines Beispielprogram zum Nachstellen.
Verfasst: 27. Januar 2007 01:24
von Takki
Also hier ein kleines Beispiel was die Linkerfehler zeigt. Im Grunde funktioniert aber eigentlich gar nichts mit Qt in Dlls... selbst die Debugversion macht Probleme unter gewissen Umständen (bezieht sich jetzt nicht auf dieses Testbeispiel).
Verfasst: 27. Januar 2007 01:58
von Takki
Lalala... ok, das Problem habe ich gefunden
Peinlich peinlich... und blind muss man sein. Bei den Release-Dlls habe ich in Wirklichkeit Exe-Dateien erstellt - kann ja nicht funktionieren
Nun crasht es nicht mehr, allerdings gibt es wohl ein paar andere Probleme. Aber erstmal weiterschauen.
So... also die seltsamen Fehler sind weg, und das Problem mit den Crashes in der Debug-Version scheint an den Timern zu liegen (in der Release-Version crasht es an der Stelle nicht, sondern es gibt eine Fehlermeldung die besagt, dass ein Timer nicht aus einem anderen Thread heraus gestoppt oder gekillt werden kann). Mich wundert das Gemeckere über Threads jedoch auch, denn eigentlich lege ich keine weiteren an...
Aber dieses Problem scheint mir lösbarer als das Andere. Aber jetzt sollte ich langsam erstmal ins Bett