Hallo,
ich habe eine QT Anwendung geschrieben. Wenn ich vom Designer aus
starte, ist alles OK. Wenn ich das Release build ausserhalb starten
möchte, gibt es Fehlermeldungen, QT Corelib.dll und irgendeine MinGw DLL
nicht gefunden.
Wie kann ich das vermeiden? Ich möchte eine exe haben, die nach
Möglichkeit auf jedem PC läuft- also unter Windows zumindest.
ps. in der Projektdatei habe ich schon config+=static versucht, jedoch
keine Änderung erreicht.
Vorab Vielen Dank!
Grüße
Michael
... ... ... schrieb:> Statisch ist aber nicht so toll
Warum? Statisches Linken erzeugt zwar größere Exe-Files, aber macht
Installationsprogramme und das herumschleppen irgendwelcher DLLs
entbehrlich.
Wobei bei intelligentem Aufbau der statischen Libraries das statisch
gelinkte Resultat durchaus deutlich kleiner sein kann als die Summe aus
dynamisch gelinktem Exe-File und erforderlicher DLLs.
Welche realen Nachteile siehst Du bei statisch gelinkten Exe-Files?
Hallo und vielen Dank erstmal.
Da ich nur kleine Tools erstelle, ist es viel einfacher, wenn ich diese
ohne Installer etc. weitergeben kann.
Es wäre schön, wenn jemand einen Weg aufzeigen könnte, wie das unter QT
geht.
Vielen Dank!
Grüße
Michael
Rufus t. Firefly schrieb:> Welche realen Nachteile siehst Du bei statisch gelinkten Exe-Files?
Pauschal die Größe, ist hier aber anscheinend nicht so wichtig. Hier,
dass er erstmal Qt neukompilieren muss. Ob sich der Aufwand lohnt, muss
er natürlich selbst entscheiden.
Michael schrieb:> Es wäre schön, wenn jemand einen Weg aufzeigen könnte, wie das unter QT> geht.
Funktioniert mein Link von oben nicht? Ansonsten, hier ist noch einer:
http://doc.qt.nokia.com/4.6/deployment-windows.html
Rufus t. Firefly schrieb:> Welche realen Nachteile siehst Du bei statisch gelinkten Exe-Files?
Ist nur für Open-Source Anwendungen zulässig.
Kommerzielle Software muss entweder mit der Kauf-Version der QT erstellt
sein, oder dynamisch gegen die LGPL-QT-DLLs gelinkt werden, damit der
End-User die Möglichkeit behält die QT selbst zu ändern und eine
angepasste Version zu verwenden...
Solltest du keine Lust auf ein Neukompilieren von Qt haben und eine
einfache KOSTENFREIE Möglichkeit eines Installers suchst kann ich dir
InnoSetup empfehlen!
Nullsoft (die Leute hinter Winamp) stellen mit NSIS ebenfalls einen
kostenfreien Installer zur Verfügung:
http://nsis.sourceforge.net/Main_Page
Aber einen Installer benötigt man eben nicht, wenn man statisch linkt.
Und die Qt-Libraries in der statischen Version zu erzeugen sollte keine
Raketenwissenschaft sein.
Rufus t. Firefly schrieb:> Aber einen Installer benötigt man eben nicht, wenn man statisch linkt.> Und die Qt-Libraries in der statischen Version zu erzeugen sollte keine> Raketenwissenschaft sein.
Die Neu-Kompiliererei nervt aber schon sehr, weil sie doch recht lange
dauert. Überhaupt habe ich nie verstanden, warum man Qt nach dem
Installieren erst noch übersetzen muss - wenn ich mir ein Java SDK
installiere, dann läuft das einfach.
Mark Brandis schrieb:> Die Neu-Kompiliererei nervt aber schon sehr, weil sie doch recht lange> dauert.
Muss man einmal machen.
Mark Brandis schrieb:> Überhaupt habe ich nie verstanden, warum man Qt nach dem> Installieren erst noch übersetzen muss
Es wird halt ohne fertig compilierte Libraries ausgeliefert, die nämlich
sind compilerspezifisch. Also müssten entweder für verschiedene
verbreitete Compiler und Betriebssysteme unterschiedliche
Auslieferungspakete für Qt existieren oder aber das Auslieferungspaket
wird riesig.
Also wird der Sourcecode ausgeliefert, und den übersetzt man einmal in
allen benötigten Varianten mit seinem eigenen Compiler.
> - wenn ich mir ein Java SDK installiere, dann läuft das einfach.
Da wird ja auch nichts übersetzt, aber ohne JRE läuft da gar nichts.
Rufus t. Firefly schrieb:> Mark Brandis schrieb:>> Die Neu-Kompiliererei nervt aber schon sehr, weil sie doch recht lange>> dauert.>> Muss man einmal machen.
Zweimal, wenn man dynamisch und statisch linken können will ;-)
> Also müssten entweder für verschiedene> verbreitete Compiler und Betriebssysteme unterschiedliche> Auslieferungspakete für Qt existieren oder aber das Auslieferungspaket> wird riesig.
Unterschiedliche Auslieferungspakete für die Betriebssysteme gibt es ja
sowieso schon. Was man machen könnte ist, den jeweils am weitesten
verbreiteten Compiler je Plattform als Standard anzunehmen und das
Package dementsprechend auszuliefern, und wer einen anderen als diesen
Compiler verwendet, der muss dann eben neu übersetzen.
Hallo,
ich habe nach den Anleitungen gearbeitet
configure -static
mingw32-make
und nun folgendes Problem:
Beim Make gibt es viele Fehlermeldungen:
undefined reference to
und dann Qassert...
QBytearray...
und und und.
Make endet mit einem Fehler.
Kann mir jemand helfen?
QT Designer kann auch nichts mehr erstellen. Fehlermeldung
moc_mainwondow.cpp und nichts weiter.
Gruß Michael
Hast Du in der Umgebungsvariablen PATH die entsprechenden Pfade
eingetragen? Bei mir z.B.
D:\Programme\MinGW\bin;D:\Programme\Qt\2010.02.1\bin;D:\Programme\Qt\201
0.02.1\qt\bin
Kixx schrieb:> wobei zwei DLL Dateien mit in den exe Ordner zu legen jetzt doch auch> nicht das Problem sein dürfte oder ;-) ...
Hallo,
ja es stimmt. Im Grunde kein Problem, wenn man es weiter gibt gibt es
Probleme.
Aber ich kann ja das Release nicht mal auf meinem PC starten.
Fehlermeldung:
"Der Prozedureinsprung "_Z5qFreePv" wurde in der DLL "QtCore4.dll" nicht
gefunden.
Ich habe einen Dependency Walker laufen lassen.
2 DLL's kann ich nirgens auf meinem System finden:
Wer.DLL und IESHIMS.DLL
Hat jemand einen Tipp? Ach ja den Versuch mit cofing static habe ich
durch Neuinstallation wieder rückgängig gemacht.
Grüße Michael
Hallo Michael,
hab den Release Ordner bei weitergabe immer komplett weitergegeben, das
hat bis dato noch keine Prob's gegeben.
Wobei ich dazu anmerken muss, das ich auch immer die Anwendung auf das
Zielsystem kopiert habe.
Das mit dem Einsprungspunkt klingt ein wenig da nach das die Qt*.dll mit
nem anderem Kompiler übersetzt wurde als dein Programm ?
eventuell opensource qt und windows kompiler Prog. übersetzt ?
Gruß Kixx
Neugierige Frage:
Wozu braucht man eigentlich Qt unter Windows, wenn man nur "kleine
Tools" entwickelt ?
Das soll jetzt keine Kritik sein, ich hab nie mit Qt zu tun gehabt.
Hallo Kixx,
so tief stecke ich da nicht drin. Ich habe lediglich QT installiert-
wohlgemerk unter Windows. Unter QT kann ich das Programm starten.
Wenn ich ein Release erstelle und es vom Explorer aus ausführen möchte,
kommt erst die Frage nach den DLL's. Die habe ich dann in den Ordner
kopiert (Aus den QT Ordnern heraus).
Und es lässt sich nicht starten.
Michael
@ich
QT ist halt ne andere Klassensammlung als z.B. die MFC von MS der
Vorteil
ist (wenn mann sich an die reinen QT Klassen hält) das die Programme
ebenso für andere BS z.B. Linux leicht zu übersetzen sind, da es hier
die QT Lib ebenfalls gibt.
@Michael
(sind nur Fragen über die ich auch schon gestolpert bin)
- 1. es gibt ne unterschied zwischen QT Debug *.dll und QT Release.dll's
erkennbar an dem zusätzlichen d vor der 4 im Namen z.B. QtSql4.dll
und QtSqld4.dll
- 2 ist die Release Version auch wirlich eine (Projekte ->
Build - Einstellungen -> auf Release schalten steht bei qmake am
Ende
config+=release)
- 3 mal unter erstellen auf alles bereinigen und anschließend qmake
ausführen und nochmal neu übersetzen (wirkt manchmal Wunder)
Hallo Kixx,
vielen Dank!.
allerdings ist es ohne Änderung.
die config ist release.
Die DLL's habe ich aus qt/bin kopiert.
Die Fehlermeldung ist wie oben.
Muss ich im Projekt noch was einbinden?
Michael
Wenn du mal spaßenshalber ein neues Projekt Qt GUI Projekt erstellst
(Mit dem Assi unter Datei -> Neues Projekt )und in dieses nichts weiter
einfügst, muss nur die QtCore4.dll und noch die QtGui4.dll (glaub ich)
mit in den Release Ordner und das Ding muss starten.
(Nach nem Übersetzungslauf versteht sich...)
Geht das ?
Hallo Kixx,
Nein das ging nicht. Aber das mit den DLL Versionen war der richtige
Weg.
Ich habe die core und die gui dll in 2 Versionen. unter qt\2010.04\bin
liegt die Dateiversion 4.7.0.0 unter qt\2010.04\qt\bin liegt die Version
4.6.3.0.
Wenn ich die neuere benutze (IM Release Verzeichnis), gibt es die
Fehlermeldung. Mit der alten Version läuft es, auch meine ursprüngliche
Anwendung.
Mark Brandis schrieb:> Hast Du in der Umgebungsvariablen PATH die entsprechenden Pfade> eingetragen? Bei mir z.B.>> D:\Programme\MinGW\bin;D:\Programme\Qt\2010.02.1\bin;D:\Programme\Qt\201
0.02.1\qt\bin
Hallo Mark,
ja die habe ich in PATH aufgenommen. Das Resultat bleibt gleich.
Michael
Michael schrieb:> Aber das mit den DLL Versionen war der richtige> Weg.
Wird so allmählich klar, warum das statische Linken doch irgendwie zu
bevorzugen ist?
Rufus t. Firefly schrieb:> Michael schrieb:>> Aber das mit den DLL Versionen war der richtige>> Weg.>> Wird so allmählich klar, warum das statische Linken doch irgendwie zu> bevorzugen ist?
Braucht er dann nicht trotzdem noch die mingw DLL dazu? Und zwei Files
werdens trotzdem, entweder EXE+QT-DLL oder Statische EXE +
Source-Code-Archiv, wenn ich den achten? Post richtig verstanden hab...
Εrnst B✶ schrieb:> Braucht er dann nicht trotzdem noch die mingw DLL dazu?
Dann wäre es kein statisches Linken.
Das Sourcecodearchiv ist zum Laufenlassen des Programmes natürlich nicht
erforderlich, das muss nur aus lizenzrechtlichen Gründen zur Verfügung
gestellt werden (was meiner Auffassung nicht impliziert, daß es
prinzipiell mit jeder Auslieferungsform der Anwendung auch mitgeliefert
werden muss).
Hallo,
EagleUser,
Danke für die ausführliche Anleitung.
OK ich habe weiterhin MinGW unter qt verwendet.
Die Path Einträge ergänzt, wie von dir beschrieben.
Ich komme bis zum 2. make.
Das wird dann mit folgenden Fehlern abgebrochen. Da fehlt noch was.
Könntest Du mir sagen, was dewr Grund ist /sein könnte?
Grüße Michael
@Rufus t. Firefly
> Wird so allmählich klar, warum das statische Linken doch irgendwie zu> bevorzugen ist?
Wie mann sieht sind beide Wege (statisch & dynamisch) nicht leicht
zu beschreiten ;-)
(nicht persönlich nehmen @Michael)
Die Fehlermeldungen lassen darauf schließen, daß eine Importlibrary
fehlt - das widerspricht irgendwie dem statischen Linken.
Ist das ganze Projekt nach Umstellung auf statisches Linken einmal
komplett neu übersetzt worden?
Dann darf eigentlich nirgends ein Symbol namens _imp___xxxx verwendet
werden.
(Übrigens kann man den Text, der unter Windows in einem Konsolenfenster
ausgegeben wird, leicht in die Zwischenablage kopieren, dafür braucht es
keinen Screenshot ... Rechtklick in das Konsolenfenster und "Markieren"
aufrufen, oder, wenn der Quickedit-Modus aktiv ist, mit gedrückter
linker Maustaste den gewünschten Bereich markieren und mit der
Return-Taste in die Zwischenablage kopieren)
Rufus t. Firefly schrieb:> Die Fehlermeldungen lassen darauf schließen, daß eine Importlibrary> fehlt - das widerspricht irgendwie dem statischen Linken.> Ist das ganze Projekt nach Umstellung auf statisches Linken einmal> komplett neu übersetzt worden?>> Dann darf eigentlich nirgends ein Symbol namens _imp___xxxx verwendet> werden.
Hallo,
das Problem tritt auf, wenn QT mit -static erstellt wird.
Grüße Michael
Rufus t. Firefly schrieb:> Εrnst B✶ schrieb:>> Braucht er dann nicht trotzdem noch die mingw DLL dazu?>> Dann wäre es kein statisches Linken.
Man kann auch an Qt statisch und an mingw dynamisch linken. Wenn man
alles statisch will, wird man sich auch mingw selbst übersetzen müssen,
da es davon meines Wissens keine schon fertige statische Version gibt.
> Das Sourcecodearchiv ist zum Laufenlassen des Programmes natürlich> nicht erforderlich, das muss nur aus lizenzrechtlichen Gründen zur> Verfügung gestellt werden
Nicht bei Qt ab Version 4.5, da das unter LGPL steht. Da muß man vom
eigenen Programm keinen Quellcode veröffentlichen, egal ob man statisch
oder dynamisch linkt. Nur wenn man an Qt selbst was ändert, muß man
diese Änderungen als Quellcode verfügbar machen.
Qt-Versionen vor 4.5 waren nur unter GPL und QPL verfügbar. Da stand das
gesamte Programm unter GPL und der Quellcode mußte auch veröffentlicht
werden, wenn man nicht die kommerzielle Version von Qt gekauft hat.
> (was meiner Auffassung nicht impliziert, daß es prinzipiell mit jeder> Auslieferungsform der Anwendung auch mitgeliefert werden muss).
Muß es nicht. Es reicht z.B. auch aus, den Quellcode auf Anfrage zum
Selbstkostenpreis auf einem Datenträger zu verschicken. Da gibt es auch
nicht viel aufzufassen, weil das praktisch wörtlich so in der GPL steht.
Rolf Magnus schrieb:> Nicht bei Qt ab Version 4.5, da das unter LGPL steht. Da muß man vom> eigenen Programm keinen Quellcode veröffentlichen, egal ob man statisch> oder dynamisch linkt.
Doch. Genau das ist der Sinn der LGPL. Dynamisch Linken oder Source (*).
Hier nochmal zum Nachlesen:
http://qt.nokia.com/about/licensing/frequently-asked-questions/
Zitat:
1
... In essence this means that Qt users may create
2
proprietary applications that dynamically link to
3
the LGPL-licensed Qt libraries ...
und
1
... The LGPL carries some restrictions regarding the ability
2
for users to relink libraries...
*) Muss deswegen nicht OpenSource werden. ggfs. reicht es auch, Statt
den Quellen nur die zwischen-Object-Files rauszugeben. Wichtig ist halt
nur dass der Endanwender eine andere QT-Version mit deiner App zusammen
verwenden kann, als die mit der ursprünglich gelinkt wurde.
Εrnst B✶ schrieb:> *) Muss deswegen nicht OpenSource werden. ggfs. reicht es auch, Statt> den Quellen nur die zwischen-Object-Files rauszugeben. Wichtig ist halt> nur dass der Endanwender eine andere QT-Version mit deiner App zusammen> verwenden kann, als die mit der ursprünglich gelinkt wurde.
Allerdings. Wobei ich auf http://www.gnu.de/documents/lgpl-2.1.de.html
auch noch folgenden skurrilen Satz gefunden habe:
1
Als Ausnahme von den Bestimmungen der vorstehenden fünf Paragraphen
2
dürfen Sie auch ein „Werk, das die Bibliothek nutzt“, mit der Bibliothek
3
kombinieren oder linken, um ein Werk zu erzeugen, das Teile der
4
Bibliothek enthält, und dieses unter Bedingungen ihrer eigenen Wahl
5
weitergeben, sofern diese Bedingungen Bearbeitungen für den eigenen
6
Gebrauch des Empfängers und ein Rückbilden (“reverse engineering”) zum
7
Beheben von Mängeln solcher Bearbeitungen gestatten.
Nun gestattet ja an sich jedes Programm ein Reengineering, in der Regel
allerdings mit einem nicht unerheblichen Aufwand.
Ich habe mich da evtl. nicht ganz klar ausgedrückt:
Der zitierte Satz sagt meinem Verständnis nach aus, daß man ein Programm
auch komplett fertig statisch an eine LGPL-Bibliothek gelinkt
closed-source vertreiben darf, wenn man in seinen Lizenzbedingungen ein
Re-Engineering erlaubt. Dabei scheint es egal zu sein, wie schwierig ein
solche Re-Engineering dann tatsächlich wäre.
Rolf Magnus schrieb:> Dabei scheint es egal zu sein, wie schwierig ein> solche Re-Engineering dann tatsächlich wäre.
Gilt da nicht noch zusätzlich der zweite Abschnitt in §6?
Also auf die Lib hinweisen, auf die LGPL hinweisen, Copyright-Vermerk
... und dann 1-aus-5 auswählen, u.A.
1
dann liefern Sie es zusammen mit dem vollständigen maschinenlesbaren
2
„Werk, das die Bibliothek nutzt“, in Form von Objektcode und/oder
3
Quelltext, so daß der Benutzer die Bibliothek verändern und dann erneut
4
linken kann, um ein verändertes ausführbares Programm zu erzeugen,
5
das die veränderte Bibliothek enthält.
oder
1
Benutzen Sie einen geeigneten „shared-library-Mechanismus“ zum
Εrnst B✶ schrieb:> Rolf Magnus schrieb:>> Dabei scheint es egal zu sein, wie schwierig ein>> solche Re-Engineering dann tatsächlich wäre.>> Gilt da nicht noch zusätzlich der zweite Abschnitt in §6?
Ja, stimmt. Was das mit dem Re-Engineering dann soll, verstehe ich aber
nicht. Wenn man die Bibliothek als Quelltext hat und dazu die
Object-Files oder den Quelltext des Programms, was muß man dann noch
re-engineeren, um die Bibliothek zu ändern?
Rolf Magnus schrieb:> Wenn man die Bibliothek als Quelltext hat und dazu die> Object-Files oder den Quelltext des Programms, was muß man dann noch> re-engineeren, um die Bibliothek zu ändern?
Vielleicht für den Fall "Binary .EXE + LGPL-Library als DLL":
Um eine geänderte DLL-Version mit geänderten Interfaces zum laufen zu
kriegen, oder auch nur einen DLL-Versionscheck in der EXE abzuschalten,
muss man halt das EXE zerpflücken dürfen.