Statisches QT und DLL erstellen
Statisches QT und DLL erstellen
Hallo,
ich habe QT neu erstellt damit ich statische Applikationen erstellen kann. Das klappt auch wunderbar.
Nun möchte ich aber eine DLL erstellen die auch QT-Funktionen enthält aber keine weiteren Abhängigkeiten hat. Wenn ich nun aber in meine .pro-Datei "CONFIG += static" oder "CONFIG += staticlib" eintrage wird die DLL nicht erstellt.
Vor dem neu erstellen der statischen QT-Version (also mit der dynamischen) wurde die DLL ordnungsgemäß erstellt. aber halt mit den Abhängigkeiten.
Grüße,
Willi
ich habe QT neu erstellt damit ich statische Applikationen erstellen kann. Das klappt auch wunderbar.
Nun möchte ich aber eine DLL erstellen die auch QT-Funktionen enthält aber keine weiteren Abhängigkeiten hat. Wenn ich nun aber in meine .pro-Datei "CONFIG += static" oder "CONFIG += staticlib" eintrage wird die DLL nicht erstellt.
Vor dem neu erstellen der statischen QT-Version (also mit der dynamischen) wurde die DLL ordnungsgemäß erstellt. aber halt mit den Abhängigkeiten.
Grüße,
Willi
Ich benutz qmake selten / gar nicht ...
Unter VS mit dem qt plugin funktioniert das aber .... hab auch dlls, die gegen ne statische qt gelinkt sind.
Wenn dir das QApp ned in die quere kommt (ich nutz es in den dlls ned, nutz nur die qtcore und qtxml) sollt es kein problem sein.
Weiss jetzt ned ob Dir das geholfen hat ...
Ciao ...
Unter VS mit dem qt plugin funktioniert das aber .... hab auch dlls, die gegen ne statische qt gelinkt sind.
Wenn dir das QApp ned in die quere kommt (ich nutz es in den dlls ned, nutz nur die qtcore und qtxml) sollt es kein problem sein.
Weiss jetzt ned ob Dir das geholfen hat ...
Ciao ...
Glaub ned das die dir so helfen ...
welchen compiler verwendest du denn ? Wie gesagt ich den VC
Da Du die qtlibs schon statisch vorliegen hasst, sollst eigentlich kein problem sein ...
Also ich geb an in welchen Verzeichnissen er die die libs zu suchen hat ...
das geht bei mir mit /LIBPATH:
Und die libs haeng ich dann alle an.
Wobei das bei dir alles das buildtool(qmake) machen sollte.
mit was steigt denn qmake aus ?
Btw, die libnamen haben sich geaendert bei mir.
Installiert (commerzielle version) werden die importlibs fuer die QT dlls als qtcore4.lib / qtcore4d.lib z.b.
Hab ich sie selber compiliert und zwar statisch, heissen die libs dann nur noch qtcore.lib / qtcored.lib
Vielleicht kommt er damit ned klar.
Ciao ...
welchen compiler verwendest du denn ? Wie gesagt ich den VC
Da Du die qtlibs schon statisch vorliegen hasst, sollst eigentlich kein problem sein ...
Also ich geb an in welchen Verzeichnissen er die die libs zu suchen hat ...
das geht bei mir mit /LIBPATH:
Und die libs haeng ich dann alle an.
Wobei das bei dir alles das buildtool(qmake) machen sollte.
mit was steigt denn qmake aus ?
Btw, die libnamen haben sich geaendert bei mir.
Installiert (commerzielle version) werden die importlibs fuer die QT dlls als qtcore4.lib / qtcore4d.lib z.b.
Hab ich sie selber compiliert und zwar statisch, heissen die libs dann nur noch qtcore.lib / qtcored.lib
Vielleicht kommt er damit ned klar.
Ciao ...
Also die bentötigten QT-Libs werden von qmake wohl angegeben. Jedenfalls enthält der Link folgende Parameter:
Aber es klappt nicht. Ich habe folgende Szenarien:
Bei Angabe von CONFIG += static oder CONFIG += staticlib gibt es zwar keine Fehler aber es wird auch keine DLL erstellt. Es wird nur die *.a erstellt weil es ja eine statische Bibliothek sein soll.
Bei Angabe von CONFIG += dll wird versucht die DLL zu erstellen (auch mit Angabe der Link-Parameter die oben angegeben sind) aber es werden alle QT-Funktionen als "unresolved" angemeckert.
ich vernde MinGW und QT 4.6.1 Commercial.
Grüße,
Willi
Code: Alles auswählen
-L"c:\Programme\Qt\2010.01\qt\lib" -lQtNetwork -lQtCore -lkernel32 -luser32 -lshell32 -luuid -lole32 -ladvapi32 -lws2_32Bei Angabe von CONFIG += static oder CONFIG += staticlib gibt es zwar keine Fehler aber es wird auch keine DLL erstellt. Es wird nur die *.a erstellt weil es ja eine statische Bibliothek sein soll.
Bei Angabe von CONFIG += dll wird versucht die DLL zu erstellen (auch mit Angabe der Link-Parameter die oben angegeben sind) aber es werden alle QT-Funktionen als "unresolved" angemeckert.
ich vernde MinGW und QT 4.6.1 Commercial.
Grüße,
Willi
kenn mich mit gcc und mingw ned so wirklich aus.Bei Angabe von CONFIG += dll wird versucht die DLL zu erstellen (auch mit Angabe der Link-Parameter die oben angegeben sind) aber es werden alle QT-Funktionen als "unresolved" angemeckert.
Aber wenn du ne lib erstellst, wird er dir nie unresolved symbole anmeckern, weil er bei ner lib den linker ned drueberschickt, sondern eigentlich nur die obj dateien in eine datei zusammenpackt ...
das heisst die verweisse koennen bei deiner statischen lib scho falsch sein.
die qt(statisch) hasst aber scho mit dem mingw compiliert und ned nen anderen compiler genommen ?
-lQTCore weisst unter linux zumindest den linker an, eine bib names libQTCore.a zuzulinken. heisst die bei dir in c:\Programme\Qt\2010.01\qt\lib auch so oder doch anders ??? Aber dann sollt er eh andere fehler (lib not found) bringen, hmmm ...
glaub ich bin mit meinem latain am ende ...
Ciao ...
KlarRHBaum hat geschrieben:kenn mich mit gcc und mingw ned so wirklich aus.
Aber wenn du ne lib erstellst, wird er dir nie unresolved symbole anmeckern, weil er bei ner lib den linker ned drueberschickt, sondern eigentlich nur die obj dateien in eine datei zusammenpackt ...
das heisst die verweisse koennen bei deiner statischen lib scho falsch sein.
die qt(statisch) hasst aber scho mit dem mingw compiliert und ned nen anderen compiler genommen ?
Es ist auch verwirrend. Wenn ich "static" oder "staticlib" mit angebe macht er auch genau das, das er alle Object-Dateien zusammenschmeißt. Aber das reicht mir halt nicht.
Ja, genau das macht der MinGW auch unter Windows. Aber genau hier scheint wohl das problem zu liegen. Irgendwie scheint er das in der Konstellation DLL mit statischem QT eben nicht zu machen. Er ignoriert wohl diese Angaben. Und ich bräuchte jetzt ein LinkerFlag um ihn doch dazu zu überreden. Die Libs an sich sind ja angegeben.RHBaum hat geschrieben:-lQTCore weisst unter linux zumindest den linker an, eine bib names libQTCore.a zuzulinken. heisst die bei dir in c:\Programme\Qt\2010.01\qt\lib auch so oder doch anders ??? Aber dann sollt er eh andere fehler (lib not found) bringen, hmmm ...
Seufz, schade. Aber trotzdem vielen Dank für Deine Mühe.RHBaum hat geschrieben:glaub ich bin mit meinem latain am ende ...
Ciao ...
Erbarmt sich vielleicht doch noch jemand?
Grüße,
Willi
Der linker ignoriert das sicher ned, wenn ihn damit befeuerst ^^
aber qmake koennt es ignoreiren oder falsch interpretieren.
Ich wuerd intensiver in der qmake hilfe suchen, zuerst ...
als alternative vielleicht mal cmake darauf ansetzen ...
oder noch anders, ne andere IDE fuer mingw die unter windows laeuft besorgen (eclipse, code:blocks) die dateien inclkudeiren das project per hand aufziehen und die compiler / linkereinstellungen haendisch machen und damit qmake umgehen. So kriegst am ehesten raus, wo es klemmt, am kompilerer/linker oder am build tool.
Ciao ...
aber qmake koennt es ignoreiren oder falsch interpretieren.
Ich wuerd intensiver in der qmake hilfe suchen, zuerst ...
als alternative vielleicht mal cmake darauf ansetzen ...
oder noch anders, ne andere IDE fuer mingw die unter windows laeuft besorgen (eclipse, code:blocks) die dateien inclkudeiren das project per hand aufziehen und die compiler / linkereinstellungen haendisch machen und damit qmake umgehen. So kriegst am ehesten raus, wo es klemmt, am kompilerer/linker oder am build tool.
Ciao ...
Also qmake generiert folgendes Linker-Statement:
Ich sehe da keine Probleme. Die ganzen Object-Files des Projektes sind in der object_script.LWTracerLib.Release Datei enthalten.
Ich weiß leider wirklich nicht mehr weiter.
Code: Alles auswählen
g++ -static -enable-stdcall-fixup -Wl,-enable-auto-import -Wl,-enable-runtime-pseudo-reloc -Wl,--output-def=release/libLWTracerLib.def -Wl,-s -shared -Wl,--out-implib,release\libLWTracerLib.a -o release\LWTracerLib.dll object_script.LWTracerLib.Release -L"c:\Programme\Qt\2010.01\qt\lib" -lQtNetwork -lQtCore -lkernel32 -luser32 -lshell32 -luuid -lole32 -ladvapi32 -lws2_32Ich weiß leider wirklich nicht mehr weiter.
Also wenn die bibs korrekt zugelinkt werden
du aber unresolved symbols fuer genau die funktionalitaeten bekommst, die in den libs stecken, weisst das auf "Probleme" beim bilden der symbolnamen hin.
Symbolnahmen werden unterschiedlich gebildet unter anderem:
- bei unterschiedlichen compilern bzw inkompatiblen kompilerversionen
- bei nichtkompatiblen compilerflags, bzw untschiedlichen runtimes
- debug / release (linkst du auch die debug versionen zu der debug app, und release zu release app ???)
Unterscheidet der mingw zwischen ner Multithreaded und ner singlethread version ?
sind irgendwelche compilerflags gesetzt worden, die die auf die importfunktionen und deren binaere ausrichtung einfluss haben (stdcall, cdecl, pascal ... und konsorten, die wirst ned direkt beeinflussen, kannst aber ueber Proprozessor direktiven indirekt beeinflussen) ...
Ciao ...
du aber unresolved symbols fuer genau die funktionalitaeten bekommst, die in den libs stecken, weisst das auf "Probleme" beim bilden der symbolnamen hin.
Symbolnahmen werden unterschiedlich gebildet unter anderem:
- bei unterschiedlichen compilern bzw inkompatiblen kompilerversionen
- bei nichtkompatiblen compilerflags, bzw untschiedlichen runtimes
- debug / release (linkst du auch die debug versionen zu der debug app, und release zu release app ???)
Unterscheidet der mingw zwischen ner Multithreaded und ner singlethread version ?
sind irgendwelche compilerflags gesetzt worden, die die auf die importfunktionen und deren binaere ausrichtung einfluss haben (stdcall, cdecl, pascal ... und konsorten, die wirst ned direkt beeinflussen, kannst aber ueber Proprozessor direktiven indirekt beeinflussen) ...
Ciao ...
Das trifft nicht zu. Alles dasselbe.RHBaum hat geschrieben:Symbolnahmen werden unterschiedlich gebildet unter anderem:
- bei unterschiedlichen compilern bzw inkompatiblen kompilerversionen
Die Flags können natürlich sein. In diese Richtung gehen meine Vermutungen ja auch.RHBaum hat geschrieben:- bei nichtkompatiblen compilerflags, bzw untschiedlichen runtimes
JapRHBaum hat geschrieben:- debug / release (linkst du auch die debug versionen zu der debug app, und release zu release app ???)
Hm, da stehe ich jetzt auf dem Schlauch!?RHBaum hat geschrieben:Unterscheidet der mingw zwischen ner Multithreaded und ner singlethread version ?
Hm, das werde ich nachher nochmal checken.RHBaum hat geschrieben:sind irgendwelche compilerflags gesetzt worden, die die auf die importfunktionen und deren binaere ausrichtung einfluss haben (stdcall, cdecl, pascal ... und konsorten, die wirst ned direkt beeinflussen, kannst aber ueber Proprozessor direktiven indirekt beeinflussen) ...
Danke,
Ciao
So, ich habe jetzt eine Lösung gefunden. Ist zwar nicht unbedingt das was man komfortabel nennt, aber wenigstens geht es. Ich lasse mir zuerst in einer Umgebung für dynamisches QT die ganzen Makefiles erzeugen und builde das Ganze einmal. Das dabei entstehende Link-Kommando hebe ich mir auf. In der statischen Umgebung werden dann ja die ganzen Objects erzeugt und ich muss das Link-Kommando einmal manuell aufrufen. Das war's dann.
Ich hoffe das wird sich noch ändern. Habe das auch bei Nokia mal nachgefragt.
Ich hoffe das wird sich noch ändern. Habe das auch bei Nokia mal nachgefragt.