QT - static build



  • Also das hat soweit funktioniert, nur das Modul "qtdeclarative" konnte nicht übersetzt werden. Dafür wird wohl zusätzlich Python benötigt, aber das musst du dann selbst einmal ausprobieren.

    Zum Schluss musst du noch in den Einstellungen die neue Qt Version hinzufügen (in meinem Beispiel wäre der Pfad "C:\qt-static\qtbase\bin\qmake.exe") und ein neues Kit mit dieser Version anlegen.



  • Schade das ich noch kein Feedback von dir habe!? Mir hat das Thema keine Ruhe gelassen, deshalb habe ich jetzt eine virtuelle Maschine mit Python aufgesetzt und kompiliere nochmal. Die Tage schreibe ich dann mal eine genaue Anleitung auf http://www.partsoft.de!



  • Ich bin gerade an der Sache dran. Ich stelle mich bei sowas immer bissel dummdödelich an, daher dauert das bei mir immer länger 😃



  • Bennisen schrieb:

    Hast du eine Lizenz? Mit der kostenlosen Version darfst du nicht statisch linken.

    Doch, darf er. Qt ist ein OpenSource Projekt das (bis auf wenige Module) ua. unter der L-GPLv2 bzw. L-GPLv3 verfügbar ist. Diese erlaubt kommerzielle Projekte unter bestimmten, einfach einzuhaltenden Bedingungen.

    http://www.gnu.org/licenses/lgpl-3.0.html
    http://www.gnu.org/licenses/gpl-faq#LGPLStaticVsDynamic

    Dennoch raten wir unseren Kunden regelmäßig vom statischen Linken ab, da es außer zusätzlicher Probleme und schwierigeren Anforderungen keinen Vorteil bietet. Schnelleren Startup erhältst du auch zB. mittels Prelinking und wenn es darum geht lediglich ein einzelnes Binary zu haben kannst du UPX Packer zB. nutzen.



  • Der Hauptgrund für das statische Linken für den firmeninternen Gebrauch ist, dass ich ein schlankes kompaktes Binary habe, ohne 50MB DLLs im Gepäck. Es ist einfach komfortabler.



  • It0101 schrieb:

    Der Hauptgrund für das statische Linken für den firmeninternen Gebrauch ist, dass ich ein schlankes kompaktes Binary habe, ohne 50MB DLLs im Gepäck. Es ist einfach komfortabler.

    Aber gerade dann will ich doch eben nicht statisch linken. Wenn du nun mehrere Programme hast können die sich nicht eine Qt Installation teilen, sondern beide schleppen alles mit.

    Wenn du nur 1 Binary zum Verteilen lieber hast, aber keinen Installer erstellen möchtest, kann ich dir UPX Packer empfehlen. Der komprimiert noch dazu das Binary.



  • Danke für den Tipp. Ich werd mir den mal angucken. Löst vielleicht auch mein Problem.



  • @picaschaf

    Danke für den Tipp, den UPX Packer werde ich mir auch einmal anschauen. Für Windows nutze ich übrigens Inno Setup, dort hat man sich relativ schnell eingearbeitet und auch Code-Signing ist kein Problem: http://www.jrsoftware.org/isinfo.php

    @It0101

    Nach der Installation von Python hat jetzt alles geklappt. Du musst in "build.cmd" dann nur den Pfad zu Python hinzufügen. Außerdem habe ich configure diesmal zusätzlich mit dem Parameter "-nomake examples" aufgerufen, denn die statisch gelinkten Beispiele belegen ca. 100 GB Speicherplatz 😮

    Aber wie versprochen schreibe ich die Tage noch eine vernünftige Anleitung dazu, dann auch für neuere Qt-Versionen.



  • InnoSetup nutzen wir auch in manchen Projekten. Wenn man sich an die Pascal Syntax gewöhnt hat oder mit den Defaults zufrieden gibt ist alles fein 😉 Damit lässt sich auch der Qt Redistributable Installer mit nur wenigen MiB als Abhängigkeit mitinstallieren. Spart bei mehreren Qt Applikationen auf dem selben Rechner Speicherplatz - löst aber natürlich nicht die altbekannte DLL Hell unter Windows.

    Weil wir hier über Qt sprechen möchte ich auch noch das Qt Installer Framework einwerfen das auch mittlerweile recht benutzbar ist und nicht mehr zwingend selbst gebaut werden muss.



  • partsoft schrieb:

    @It0101

    Nach der Installation von Python hat jetzt alles geklappt. Du musst in "build.cmd" dann nur den Pfad zu Python hinzufügen. Außerdem habe ich configure diesmal zusätzlich mit dem Parameter "-nomake examples" aufgerufen, denn die statisch gelinkten Beispiele belegen ca. 100 GB Speicherplatz 😮

    Aber wie versprochen schreibe ich die Tage noch eine vernünftige Anleitung dazu, dann auch für neuere Qt-Versionen.

    Mir ist zwischendurch auch der Speicherplatz ausgegangen. Mein "C:" ist ne SSD... naja ich habe jetzt nochmal bissel aufgeräumt und das "-nomake examples" mit reingenommen. Und dann schaue ich mal wie weit ich jetzt komme. 😉 Danke dir erstmal! Wird schon noch!



  • Anmerkung von mir: der Python-Installer generiert nicht standardmäßig die "python.exe" im Verzeichnis. Das muss man explizit im Python-Installer einrichten. Das war mein Fehler. Python installiert, aber keine Python.exe da 😉

    Kaum macht mans richtig.... 😉



  • Ich bin jetzt mit dem Build von QT fertig und habe den neuen Kit im QTCreator eingerichtet. Release-Buildprozess einer TestAnwendung hat auch soweit funktioniert.

    Nur startet die gebaute Executable trotzdem nicht.

    ".... kann nicht gestartet werden, da libgcc_s_dw2-1.dll auf dem Computer fehlt..."

    Kann das sein, dass hier bei meinem MINGW noch was nicht passt? Vermutlich muss ich im Projektfile noch eine zusätzliche Compileroption mitgeben, damit mingw dann auch die c++-Sachen statisch linkt, oder?

    Problem behoben:

    Im QTCreator-Projektfile gehört noch folgender Eintrag dazu, damit auch der Compiler es rafft:

    LIBS += -static
    

    Vielen Dank euch allen für eure Hilfe!

    Jetzt gehe ich erstmal hin und teste den Vorschlag von PicaSchaf 😉



  • Was mir noch aufgefallen ist. Mein simples Testprogramm mit einem einzigen Widget ist statisch gelinkt ganze 16MB groß...

    Ich habe damals Frontends mit CBuilder6 entwickelt und auch statisch gelinkt. Da waren selbst 2-3MB schon viel für ein Frontend mit Funktionialität.

    Aber 16MB für nix?

    Anmerkung: Der GCC-Aufruf sieht folgendermaßen aus:

    g++ -Wl,-s -Wl,-subsystem,windows -mthreads -o release\testcomp.exe release/main.o release/mainwindow.o release/qroundprogressbar.o release/testcomp_plugin_import.o release/qrc_res.o release/moc_mainwindow.o release/moc_qroundprogressbar.o -lmingw32 -LD:\qt\qt-everywhere-opensource-src-5.7.1\qtbase\lib D:\qt\qt-everywhere-opensource-src-5.7.1\qtbase\lib\libqtmain.a -static D:\qt\qt-everywhere-opensource-src-5.7.1\qtbase\lib\libQt5Widgets.a -LD:\qt\qt-everywhere-opensource-src-5.7.1\qtbase\plugins\platforms D:\qt\qt-everywhere-opensource-src-5.7.1\qtbase\plugins\platforms\libqwindows.a -lwinspool -lshlwapi D:\qt\qt-everywhere-opensource-src-5.7.1\qtbase\lib\libQt5PlatformSupport.a D:\qt\qt-everywhere-opensource-src-5.7.1\qtbase\lib\libQt5DBus.a -lnetapi32 D:\qt\qt-everywhere-opensource-src-5.7.1\qtbase\lib\libqtfreetype.a -LD:\qt\qt-everywhere-opensource-src-5.7.1\qtbase\plugins\imageformats D:\qt\qt-everywhere-opensource-src-5.7.1\qtbase\plugins\imageformats\libqdds.a D:\qt\qt-everywhere-opensource-src-5.7.1\qtbase\plugins\imageformats\libqicns.a D:\qt\qt-everywhere-opensource-src-5.7.1\qtbase\plugins\imageformats\libqico.a D:\qt\qt-everywhere-opensource-src-5.7.1\qtbase\plugins\imageformats\libqtga.a D:\qt\qt-everywhere-opensource-src-5.7.1\qtbase\plugins\imageformats\libqtiff.a D:\qt\qt-everywhere-opensource-src-5.7.1\qtbase\plugins\imageformats\libqwbmp.a D:\qt\qt-everywhere-opensource-src-5.7.1\qtbase\plugins\imageformats\libqwebp.a D:\qt\qt-everywhere-opensource-src-5.7.1\qtbase\lib\libQt5Gui.a -lcomdlg32 -loleaut32 -limm32 -lwinmm -lglu32 -lopengl32 -lgdi32 D:\qt\qt-everywhere-opensource-src-5.7.1\qtbase\lib\libqtpng.a D:\qt\qt-everywhere-opensource-src-5.7.1\qtbase\lib\libqtharfbuzzng.a D:\qt\qt-everywhere-opensource-src-5.7.1\qtbase\lib\libQt5Core.a -lole32 -luuid -lws2_32 -ladvapi32 -lshell32 -luser32 -lkernel32 -lmpr -lz D:\qt\qt-everywhere-opensource-src-5.7.1\qtbase\lib\libqtpcre.a

    Linkt QT automatisch einfach alles rein?



  • Ich habe das jetzt alles einmal sauber aufgeschrieben und auf der Website von Partsoft veröffentlicht:

    https://www.partsoft.de/index.php/de/support/cutex-1-0/15-qt-static-build



  • It0101 schrieb:

    Was mir noch aufgefallen ist. Mein simples Testprogramm mit einem einzigen Widget ist statisch gelinkt ganze 16MB groß...

    Ich habe damals Frontends mit CBuilder6 entwickelt und auch statisch gelinkt. Da waren selbst 2-3MB schon viel für ein Frontend mit Funktionialität.

    Aber 16MB für nix?

    Qt ist bestimmt umfangreicher als die Runtime vom CBuilder6



  • @PartSoft: danke! Sieht gut aus!

    1.Du könntest als Ergänzung noch diesen Link hinzufügen, wo alle möglichen Optionen für "configure" drin stehen.

    http://radekp.github.io/qtmoko/api/buildsystem/over-configure-options-qt-1.html

    Gerade, wenn man wie ich, SSL benötigt, findet man dort die notwendigen Schalter.

    2. Beim Pythoninstaller sollte man darauf hinweisen, dass er nicht vollautomatisch eine "python.exe" erzeugt, die für den QT-Buildprozess notwendig ist. Mein Pythoninstaller hat das erst nach Aufforderung getan. 😉



  • @FireFly: ich habs fast vermutet. Mich wundert schon der etwas umfangreiche Linkeraufruf mit sovielen Bibliotheken, aber vermutlich muss ich damit leben.



  • It0101 schrieb:

    @PartSoft: danke! Sieht gut aus!

    1.Du könntest als Ergänzung noch diesen Link hinzufügen, wo alle möglichen Optionen für "configure" drin stehen.

    http://radekp.github.io/qtmoko/api/buildsystem/over-configure-options-qt-1.html

    Gerade, wenn man wie ich, SSL benötigt, findet man dort die notwendigen Schalter.

    2. Beim Pythoninstaller sollte man darauf hinweisen, dass er nicht vollautomatisch eine "python.exe" erzeugt, die für den QT-Buildprozess notwendig ist. Mein Pythoninstaller hat das erst nach Aufforderung getan. 😉

    Also bei mir hat die Installation von Python problemlos geklappt, ich habe nur den Pfad geändert! Von daher lasse ich den Artikel so wie er ist, es soll ja auch nur eine grundlegende Anleitung sein.

    Ansonsten kannst du natürlich gerne auch selbst etwas dazu schreiben, der Supportbereich ist ein Forum 😉



  • Ich habe damals Frontends mit CBuilder6 entwickelt und auch statisch gelinkt. Da waren selbst 2-3MB schon viel für ein Frontend mit Funktionialität.

    Meinst du Borland C++ Builder Version 6? Der kam 2002 raus, das Teil ist also schon 15 Jahre alt! Meine Anwendungen mit Borland C++ 3.1 unter DOS waren auch wesentlich kleiner als meine heutigen Qt-Anwendungen 😉



  • Ja du hast wohl Recht. Ich hatte nicht bedacht, dass der CBuilder6 ja schon uralt ist. In der kurzen Zeit der Softwareentwicklung sind 15 Jahre ne Menge Holz.

    Dennoch stelle ich fest, dass der Trend immer mehr zu "hinklatschen" und nen größeren Speicherriegel / ne größere Platte einbauen geht, anstatt sich Gedanken über effizenze Ressourcennutzung zu machen.


Anmelden zum Antworten