[Development] Qt Static Package

Mitch Curtis mitch.curtis at qt.io
Tue Apr 23 11:04:49 CEST 2019

> -----Original Message-----
> From: Development <development-bounces at qt-project.org> On Behalf Of
> Carlos Enrique Pérez Sánchez
> Sent: Saturday, 20 April 2019 2:56 AM
> To: development at qt-project.org
> Subject: Re: [Development] Qt Static Package
> I invited Mitch Curtis to join the discussion. He may have a word on this since
> he is actively working on the Qt Quick Controls 2 module. Hope he can help
> us here. Making a working static build of Qt Quick Controls 2 can push
> forward the release of static packages.

I don't think I've ever built statically on Windows.

> the graphics effects are off, no shadows, no layer, no elevation, etc.

This sounds very similar to what I saw with linuxdeployqt a while back:


I've sinced moved to Qbs, and for a while was building statically on Linux and it solved all of the issues I had. Recently users started running into issues with missing ICU libs:


So I figured that if I'm gonna have to bundle ICU with a statically built app, I may as well try linuxdeployqt again to see if it works, and just link dynamically. Turns out it was pretty easy to fix the Qbs files to get it working:


So now I'm back to linking the app dynamically on all platforms... guess that doesn't really help you much, but that is my experience with the deployment process so far.

If I recall correctly, there are reasons why we don't do static builds in CI and offer packages for it, but I can't remember what they are. I'm not involved in that stuff, so I can't really help.

However, if you have issues with Qt Quick Controls 2 in statically built apps, please create bug reports.

> El vie., 19 abr. 2019 a las 20:31, Carlos Enrique Pérez Sánchez
> (<ceperez1996 at gmail.com <mailto:ceperez1996 at gmail.com> >) escribió:
> 	By the way. I have made no changes to my .pro file after build my
> static version of Qt. The reason is that the Qt Doc says (https://doc.qt.io/qt-
> 5/plugins-howto.html#static-plugins):
> 		Plugins can be linked statically into your application. If you
> build the static version of Qt, this is the only option for including Qt's
> predefined plugins. Using static plugins makes the deployment less error-
> prone, but has the disadvantage that no functionality from plugins can be
> added without a complete rebuild and redistribution of the application.
> 		To link plugins statically, you need to add the required plugins
> to your build using QTPLUGIN.
> 		In the .pro file for your application, you need the following
> entry:
> 		  QTPLUGIN     += qjpeg \
> 		                  qgif \
> 		                  qkrcodecs
> 		qmake automatically adds the plugins to QTPLUGIN that are
> typically needed by the Qt modules used (see QT <http://../qmake/qmake-
> variable-reference.html#qt> ), while more specialized plugins need to be
> added manually.
> 	So, according with this, I have no need of importing Qt plugind
> related to Qt Quick Controls 2. Also, I have checked that the
> qmlimportscanner works appropriatelly.
> 	The page Deploying Qt Quick Controls 2 Applications says the
> following about static linking:
> 		For dynamically built applications, it is not necessary to import
> a specific style that should be usable by that application. For statically built
> applications, Qt's build system must be involved to ensure that QML plugins
> function as expected. Specifically, qmake uses qmlimportscanner to scan the
> QML files in your application for import statements. For this reason, any
> styles that should be usable by a statically built application must explicitly
> import that style. Where the import occurs is up to the developer, but it is
> recommended to follow the approach mentioned in the Deploying an
> Application with Several Styles <http://qtquickcontrols2-
> deployment.html#deploying-an-application-with-several-styles>  section, so
> that only the minimum set of files that are necessary for a particular device
> are deployed.
> 	So, they should be built QQC2 statically before (because if not,
> document that makes no sense) and they says that the only requirement is
> explicitly importing the style plugin. Sadly, that does not work for me.
> 	El vie., 19 abr. 2019 a las 19:45, Carlos Enrique Pérez Sánchez
> (<ceperez1996 at gmail.com <mailto:ceperez1996 at gmail.com> >) escribió:
> 		Thanks, Thiago. I will build Qt statically today on Windows,
> and I will try using the system version. Same with Linux. However, I really
> don't think that doing that solves the problem with the static linking of
> QtQuick Controls 2 module. Thanks in advance.
> 		El jue., 18 abr. 2019 a las 23:23, Thiago Macieira
> (<thiago.macieira at intel.com <mailto:thiago.macieira at intel.com> >) escribió:
> 			On Friday, 19 April 2019 08:11:41 +08 Carlos Enrique
> Pérez Sánchez wrote:
> 			> ```
> 			> ./configure -prefix "/somePath/Qt512Static" -static
> -release -opensource
> 			> -confirm-license -qt-zlib -qt-pcre -qt-libpng -qt-
> libjpeg -fontconfig
> 			> -qt-xcb -opengl desktop -sql-sqlite -make libs -
> make tools -nomake examples
> 			> -nomake tests -skip qtwebengine
> 			> ```
> 			Please note the -qt-zlib option and family: if you
> choose to use the bundled
> 			versions from Qt, you'll need to monitor those
> upstreams for security issues
> 			and, if any is found, rebuild your application after
> applying the fix to the
> 			sources bundled in Qt.
> 			Far better to use -system-zlib and family.
> 			--
> 			Thiago Macieira - thiago.macieira (AT) intel.com
> <http://intel.com>
> 			  Software Architect - Intel System Software Products
> 	_______________________________________________
> 			Development mailing list
> 			Development at qt-project.org
> <mailto:Development at qt-project.org>
> 			https://lists.qt-project.org/listinfo/development

More information about the Development mailing list