[Development] Qt Static Package
Carlos Enrique Pérez Sánchez
ceperez1996 at gmail.com
Fri Apr 26 21:55:26 CEST 2019
> Note that CMake is notoriously bad when you want to build static
applications. It always prefers shared libraries when searching for
dependencies if they are present in the system.
I strongly agree. That's why I'm back to qmake. I hope that the people of
Qt Company add support for static builds with CMake if they choose it as
the default build system (hope they do, since CMake is used for many
projects, not only Qt apps).
El vie., 26 abr. 2019 a las 15:50, Konstantin Tokarev (<annulen at yandex.ru>)
escribió:
>
>
> 26.04.2019, 22:47, "Carlos Enrique Pérez Sánchez" <ceperez1996 at gmail.com>:
> >> This sounds very similar to what I saw with linuxdeployqt a while back
> > Currently, I can link dynamically on Linux (using qmake to generate the
> makefile) and make a standalone executable with linuxdeployqt and it works
> well. I do have to add some dependencies manually like the svg module (even
> if I add it to the .pro file) but after that it works well.
> > Regarding static builds, I have a few issues on Linux but none of them
> are related directly to Qt. After install the corresponding -dev package
> the related dependency issue is gone. However, it is hard to track all
> dependencies and make another build every time something goes wrong because
> I have a low-power device so the build process takes about 8 hours. So,
> instead, I'm linking dynamically on Linux using linuxdeployqt.
> >
> >> 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
> > I'm using qmake because there is not Qbs option in Qt 5.12 (at least on
> Linux, opensource license). Also, I have zero experience with Qbs, but I
> will give it a try if you suggest so, but...
> > the command line options to pass to configure are exactly the same?
> > BTW: Can you post the command line you use to build Qt statically?
> > I want to start using CMake since that will be (apparently) the build
> system by default on Qt6, but the people who I know that tried so have
> failed even with Qt Widgets applications, so I suppose that CMake is not
> ready for that yet (without some undocumented developer intervention at
> least).
>
> Note that CMake is notoriously bad when you want to build static
> applications. It always prefers shared libraries when searching for
> dependencies if they are present in the system.
>
> >
> >> 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.
> > I see. But note that in QTBUG-72810 the assignee agree about providing
> static packages, so I think that it should be possible. If not in the CI (I
> know that it is very large right now, so adding more stuff is not easy)
> maybe on alternative servers or only for LTS versions, etc.
> >
> >> However, if you have issues with Qt Quick Controls 2 in statically
> built apps, please create bug reports.
> > Ok. I will collect more information and then do that. First, a report
> about documenting appropriately the static build process, as the Qt Doc is
> very poor in that matter. Second, present my static problem with Qt Quick
> Controls 2.
> >
> > Thanks for reply, I really appreciate it.
> >
> > El mar., 23 abr. 2019 a las 5:04, Mitch Curtis (<mitch.curtis at qt.io>)
> escribió:
> >>> -----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:
> >>
> >> https://github.com/probonopd/linuxdeployqt/issues/280
> >>
> >> 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:
> >>
> >> https://github.com/mitchcurtis/slate/issues/112
> >>
> >> 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:
> >>
> >>
> https://github.com/mitchcurtis/slate/commit/4bede2be54a194f9bc033d56e4df3d300065415a
> >>
> >> 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
> >>>
> > ,
> >
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org
> > https://lists.qt-project.org/listinfo/development
>
>
> --
> Regards,
> Konstantin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190426/e65a4509/attachment.html>
More information about the Development
mailing list