[Development] Qt Static Package
Carlos Enrique Pérez Sánchez
ceperez1996 at gmail.com
Fri Apr 19 02:11:41 CEST 2019
> There are many ways that are much better and do not have the problems
> static linking involves.
Many ways much better?
Static linking is the recommended approach on Linux. And the people from
the company uses static linking to build some Qt tools for linux (I have
already checked that).
Why should anyone recommend static linking for applications that use Qt?
> What should the advantages be? TQC would probably, with their posionous
> view on L-GPL usage.
Static linking is indeed an interesting topic when we take licenses into
account. And that is something that is already documented in Qt Help.
However I think that with the resource system and with the "new" QML engine
that can get the QML files from resources, the problems of static linking
are no much different from the problems of dynamic linking, taking in
account that all data in dynamic linking eighter is binary or can be
embedded as a binary resource.
I recommend static linking because:
1. The size of the application is less than the overall size of
app+libs+etc in dynamic linking.
2. The deployment process is cleaner, easier, simpler.
3. You end with a lot less dependencies issues on Linux.
4. You can make your own custom installer for a specific application.
The use case of installers is indeed a point: you can't have an installer
that links dynamically. Qt Installer Framework has some issues concerning
offline updates, and many people have migrate to other installer frameworks
like NSIS, but they are usually not cross-platform or ugly, or no
intuitive. Qt Inst. Frw. is built statically, but it uses Qt Widgets. Just
Imagine a fluid UI on Qt Installer Framework using Qt Quick Controls 2.
That will provide the best UX possible. It must be built against a static
version of Qt. I don't know if they have done so or not, but I can't
statically link with QQC2 (and I have been trying for 2 years), so building
Qt Statically must be, at least, well documented.
The issue is classified as P2 (important), and they assignee agree about
providing static packages on the online installer.
> Better yet: instead of upvoting, omeone post the full command-line that
> produces a working build.
I agree, Thiago. But the issue is classified as P2, so I think that, at
least, they will try. My best command line result is:
./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
configure -prefix "C:/somePath/QtStatic" -static -static-runtime -release
-opensource -confirm-license -qt-zlib -qt-pcre -qt-libpng -qt-libjpeg
-opengl desktop -sql-sqlite -qt-freetype -make libs -make tools -nomake
examples -nomake tests -skip qtwebengine
Sadly that does not work well with the QQC2 module (mainly under Windows),
as applications shows no effects (elevation, shadows, etc). It may be a
linking problem (I hope so) or maybe a problem with the Qt Graphical
Effects module. Not sure.
El dom., 14 abr. 2019 a las 19:47, Carlos Enrique Pérez Sánchez (<
ceperez1996 at gmail.com>) escribió:
> What do people think about providing official static packages?
> The reason is that the distribution of an application is much easier in a
> single executable. For that reasons I've made many static qt builds and
> it's always a lot of work to make it running.
> I have success in building qt statically for console and widgets
> applications, but I have not success on building Qt Quick Controls 2
> applications statically, mainly on Windows, because the graphics effects
> are off, no shadows, no layer, no elevation, etc.
> There internet is full of people trying to build Qt statically, because Qt
> Docs lacks information about building static packages and there are not
> examples of commands to pass to configure. People even migrated to other
> frameworks because they like static applications, and in Qt doing that is
> always a pain.
> There is a Jira suggestion:
> Please give an upvote there it if you agree.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development