qtforum.de

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

Darf ich das nochmal pushen? Ist die Frage denn verstanden? Notwendig ist das Ganze weil wir eine DLL zum verteilen haben wollen und diese auch aus anderen Spachen aufrufbar sein soll.

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 ...

Zuerst mal vielen Dank das Du Dich gemeldet hast

So richtig hat es mir leider noch nicht weitergeholfen. Abgesehen davon das ich jetzt weiß das es geht. Könntest Du mir Deine Link-Parameter geben?

Danke,
Willi

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 ...

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

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.

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 ?

-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 ...

RHBaum 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 ?

Klar Das habe ich mit demselben Compiler erstellt.

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.

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 ...

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:glaub ich bin mit meinem latain am ende ...

Ciao ...

Seufz, schade. Aber trotzdem vielen Dank für Deine Mühe.

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 ...

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.

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 ...

RHBaum hat geschrieben:Symbolnahmen werden unterschiedlich gebildet unter anderem:
- bei unterschiedlichen compilern bzw inkompatiblen kompilerversionen

Das trifft nicht zu. Alles dasselbe.

RHBaum hat geschrieben:- bei nichtkompatiblen compilerflags, bzw untschiedlichen runtimes

Die Flags können natürlich sein. In diese Richtung gehen meine Vermutungen ja auch.

RHBaum hat geschrieben:- debug / release (linkst du auch die debug versionen zu der debug app, und release zu release app ???)

Jap

RHBaum hat geschrieben:Unterscheidet der mingw zwischen ner Multithreaded und ner singlethread version ?

Hm, da stehe ich jetzt auf dem Schlauch!?

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) ...

Hm, das werde ich nachher nochmal checken.

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.

So, das Problem ist gelöst. Folgende 2 Definitionen müssen in die .pro-Datei noch mit aufgenommen werden damit es mit dem QtCreator auch automatisch funktioniert:

CONFIG += qt \
dll
contains(CONFIG, static):DEFINES += QT_NODLL

Ich frage mich jetzt nur wo man sowas nachlesen kann.