Solved Statically build app still requires .dll files
-
Hello guys!
I tried to build a static application according to this guide:
https://wiki.qt.io/Build_Standalone_Qt_Application_for_Windows
and everything seemed to be working fine.I used the nmake command from "x64 Native Tools Command Prompt for VS 2017" and used MSVC2017 64bit in my project.
My PATH includes:
"C:\Qt\Qt5.13.0\5.13.0\msvc2017_64\bin"
"C:\Program Files (x86)\Windows Kits\10\bin\x64"but my .exe file still requires .dll files (from Qt) when it's used on a different machine
after I build the static version of Qt, my Qt installation path looks like this:
C:\Qt
C:\Qtoldmy .pro file looks like this:
#------------------------------------------------- # # Project created by QtCreator 2019-08-16T09:17:07 # #------------------------------------------------- QT += core gui widgets printsupport webenginewidgets webchannel websockets greaterThan(QT_MAJOR_VERSION, 5): QT += widgets TARGET = PA_creator TEMPLATE = app # The following define makes your compiler emit warnings if you use # any feature of Qt which has been marked as deprecated (the exact warnings # depend on your compiler). Please consult the documentation of the # deprecated API in order to know how to port your code away from it. DEFINES += QT_DEPRECATED_WARNINGS # You can also make your code fail to compile if you use deprecated APIs. # In order to do so, uncomment the following line. # You can also select to disable deprecated APIs only up to a certain version of Qt. #DEFINES += QT_DISABLE_DEPRECATED_BEFORE=0x060000 # disables all the APIs deprecated before Qt 6.0.0 CONFIG += c++11 static INCLUDEPATH += "C:/Program Files (x86)/Visual Leak Detector/include/" LIBS += -L"C:/Program Files (x86)/Visual Leak Detector/lib/Win64" SOURCES += \ datapassing.cpp \ main.cpp \ mainwindow.cpp \ pdfwindow.cpp \ potenzialandspecifics.cpp \ specificandbutton.cpp \ taskandpotenziale.cpp HEADERS += \ datapassing.h \ mainwindow.h \ pdfwindow.h \ potenzialandspecifics.h \ specificandbutton.h \ taskandpotenziale.h FORMS += \ mainwindow.ui \ pdfwindow.ui #Manifest win32 { QMAKE_POST_LINK += mt -nologo -manifest $$PWD/manifest.xml -outputresource:$$OUT_PWD/release/$$TARGET".exe" $$escape_expand(\n\t) } # Default rules for deployment. qnx: target.path = /tmp/$${TARGET}/bin else: unix:!android: target.path = /opt/$${TARGET}/bin !isEmpty(target.path): INSTALLS += target RESOURCES += \ resources.qrc DISTFILES +=
Feel free to ask for more information, and thank you for your time and help!
-
Hi,
What exact dlls does your application need ?
If these are from the Visual Studio runtimes then it means that you didn't modify Qt to link against the static runtime.In a side note, don't forget the constraints that come with a static build of Qt.
-
Hey, thank you for your reply,
it misses dlls like
"Qt5WebEngineWidgets.dll" and
"Qt5WebChannel.dll"After inserting them alongside the application, it misses other dlls like:
"Qt5WebEngineCore.dll",
"Qt5Quick.dll",
"Qt5Network.dll" and
"Qt5QuickWidgets.dll"Is there a possibility, that I did not successfully build the static version of Qt, therefore my app is still build dynamically linked?
Are there other constraints except licencing issues and not being able to use dlls (and therefore having to rebuild to update)?Btw. two general questions regarding Qt app software design:
If I want to load and use a configuration file (e.g. in json-format) on runtime to build my gui dependend on the contents of the file, would this even be possible with a static application?
Or should I just go with a dynamically linked app and put all the .dll "clutter" my colleague should not deal with in subfolders?The workflow required to deploy a Windows app seems kinda out of place compared how great the framework and creator-IDE are ^^
-
QtWebEngine due to chromium is a different beast. It can't be built statically. This is unrelated to licensing constraints.
Using a dynamic or static build does not play any role with regards to creating a dynamic interface.
As for the .dll clutter you mention, it's nothing Qt specific. It's how Windows deployment works. The task is made easier with windeployqt.
-
Ok thank you for the info!