Arch Linux User Repository

Notes regarding 5.15.1 update

• With this update I finally splitted all static libraries from further Qt repositories into their own packages as well. So now there's not only mingw-w64-qt5-base-static but also mingw-w64-qt5-svg-static, mingw-w64-qt5-declarative-static and so on. The static version is still sharing files with the shared version and as such depends on the shared packages. However, this change allows to avoid building all the static libraries if only shared libraries are required. If you've so far used static libraries from further Qt modules be sure to install the additional *-static packages.
• Otherwise there were not much build system changes on the Qt side so I don't think this update broke much.
• As stated in the sticky comment I'm thinking about Qt 6 packaging but this also means I'm not going to take much effort to address any outstanding bugs/limitations for the Qt 5 packages anymore (broken ANGLE build, build Qt WebEngine, …).
• This is the last official release of the 5.x. Let's see whether further updates for the 5.x branch will be made available by the community. If the regular qt5-base packages picks up such commits I could update this package here as well.

Notes regarding Qt 6 packaging

• The Qt devs are discussion about their build system again: https://lists.qt-project.org/pipermail/development/2020-June/039673.html
• The thread contained some interesting links, e.g. https://code.qt.io/cgit/qt/qtbase.git/tree/cmake/README.md contains points relevant to consider when packaging Qt 6 with regards to cross compilation.

I plan to package Qt 6 as well (see https://aur.archlinux.org/packages/mingw-w64-qt6-base for a WIP version), so here are the changes I expect I'll have to make:

1. The mingw-w64-qt5-* packages stay mainly as-is.
   1. Of course I'll be updating the patch version. If a community fork for minor version updates is created and picked up by the regular qt5-* packages it would make sense to do the same for mingw-w64-qt5-* packages.
   2. As a "final improvement" for the Qt 5 packaging I could also apply the shared vs. static splitting for all modules. Currently it is a bit weird to have a separate *-static package for the base repository but not for other repositories.
   3. ANGLE seems to be completely abandoned by Qt 6 in favor of platform-specific backends. That means I'm not going to take any effort anymore in fixing the currently broken ANGLE variant.
2. I'll create mingw-w64-qt6-* packages for Qt 6.
   1. CMake will be the only supported build system for building Qt itself so I'll switch to that.
   2. All "host tools" need to come from the regular qt6-* packages. I consider that an improvement because it takes out complexity from the build system and also avoids redundancy. It is also more consistent with other packages, e.g. if some package needs Python to generate something during the build we also don't try to bootstrap a minimal version of Python during the build but instead simply depend on the python package.
      1. That also affects qmake. When I understand it correctly, that means all qmake-based projects will need to depend on the regular package which will provide the qmake binary. Likely it makes sense to create a package called mingw-w64-qt6-qmake which would be similar to mingw-w64-cmake so not every package would have to sort out the correct usage individually.
      2. I'll delay building the mingw-w64-qt6-* packages until the corresponding qt6-* are available because I suppose using older tools might not generally work.
      3. Not sure how we'll have to built the deployment tool or generally other Windows specific tools. They will likely not be available within the regular GNU/Linux packages but are still host tools. Maybe one simply builds these in a separate CMake/make invocation using some special parameters.
   3. I'll drop my patches for supporting installing the shared and static version within the same prefix. These patches actually came from the previous maintainer who took them from Fedora. I kept these patches so far because why change a running system. However, now I'd likely need to rewrite the patches completely so it makes more sense to get rid of them. That means I'll use a nested install prefix for the static version similar to the MSYS2 packaging. That means you will no longer be able to use the shared and the static version of Qt within the same CMake project. This was a nice feature but I don't think the benefit is worth the maintenance effort anymore.
   4. Cross compilation for the mingw-w64 target is still not officially supported. So I'll expect to run into problems and I don't expect that Qt 6 packages will be ready immediately after its release (although I'll likely try out beta versions).
   5. Some Qt modules will be moved out to the market place (e.g. Qt Multimedia). This mainly affects the repository URL and decouples these modules from the regular Qt release cycle. I think it makes actually sense because this way we can likely avoid frequent rebuilds of modules which don't change anyways (unless they are using private Qt APIs).

Feel free to comment if you have any ideas or suggestions. Of course we're quite constrained to how upstream plans to do things.

Before upgrading, be sure to remove the old version of the package from your system. Preferably, build the package in a clean chroot using makechrootpkg.

Also, please read the other comments and issues on GitHub for known bugs and limitations.

There also exist a binary repository: https://martchus.no-ip.biz/repo/arch/ownstuff, https://wiki.archlinux.org/index.php/Unofficial_user_repositories#ownstuff

@theone74 It is currently not possible to use the MariaDB plugin with the static version of Qt because mariadb-connector-c comes with its own pthread implementation which has conflicting symbols with the pthread library Qt uses. Since some PostgreSQL update the same is true for the PostgreSQL plugin.

So you have to disable the plugin. When using CMake, plugins are not be automatically added so you should not run into the issue by default. When using qmake you need to disable the plugin manually, eg. you can add the following arguments to enable only the plugins which actually work:

CONFIG+=no_smart_library_merge QTPLUGIN.sqldrivers=qsqlite QTPLUGIN.sqldrivers+=qsqlodbc CONFIG+=static

(https://github.com/Martchus/PKGBUILDs/blob/master/qt5-tools/mingw-w64-static/PKGBUILD#L45)

All my packages are managed at GitHub where you can also contribute directly: https://github.com/Martchus/PKGBUILDs

Patches for this package are managed at: https://github.com/Martchus/qtbase/tree/5.11.0-mingw-w64
if you like to contribute to patches, read this: https://github.com/Martchus/PKGBUILDs/#contributing-to-patches

If you would like to contribute, here is a list of known bugs and things needing improvement:

• The linker library search paths for applications which need to be build for the host architecture aren't set correctly. Hence those paths are currently set manually which is quite hacky. Affected packages are mingw-w64-qt5-declarative and mingw-w64-qt5-tools and (also the apple-darwin versions).
• Compiling QtAV using the ANGLE version doesn't work. I don't know whether other applications/libs using OpenGL via Qt are also affected but it is very likely.
• Updating mingw-w64-qt5-webkit to ng version.
• See also https://github.com/Martchus/PKGBUILDs/issues

Also note the comments about the different variants inside the PKGBUILD itself.

I'll push 5.10.0 when the regular package is moved from testing to extra:

• The following new packages are available
  • mingw-w64-qt5-speech: without flite and speech-dispatcher backends because mingw-w64 packages for those dependencies are not available
  • mingw-w64-qt5-remoteobjects
  • mingw-w64-qt5-networkauth
• Using MariaDB with the static version still does not work, see comment: https://aur.archlinux.org/packages/mingw-w64-mariadb-connector-c
• Rough edges about the static version are still not gone.
  • However, I'm able to build qmake projects (eg. all Qt modules) by just adding 'CONFIG+=no_smart_library_merge CONFIG+=static' to qmake arguments and it includes platform plugins.
  • When using CMake, I'm currently getting a -L/lib on the linker line leading to linker segfault. This issue was already present some time ago, have to further investigate where this cross-compilation-disturbing search path comes from.
• I disabled building the mapbox-gl plugin in mingw-w64-qt5-location as it takes a significat time to compile and is likely not used by a lot of people. To enable it, see the comment in the corresponding PKGBUILD.
• Updating mingw-w64-qt5-webkit to ng version is still TODO.

(Updated PKGBUILDs are already pushed to https://github.com/Martchus/PKGBUILDs.)

Qt 5.9.3 is out. However, I'm a bit busy next week so maybe I just skip that release and update to 5.10 right away. 5.10 is likely to be released in the beginning of December which is also quite close.

@Martchus: Thanks, I uninstalled and built and installed again. I tried to make it work with extra-x86_64-build but there were too many dependencies to manually add... I'll remember for next time. Thanks for maintaining the package!

Seems like it tries to link Qt Widgets against the currently installed version of Qt Core and Gui. This is not possible because private ABI might (and actually has) changed. Hence those linker errors only relate to private symbols of the Qt library.

Not sure what makes Qt linking against the installed/previous version now. I'd simply work around this by uninstalling the previous version or build in a clean chroot. I always do the latter and hence didn't encounter this issue when building myself.

I get link errors with 5.9.2:

i686-w64-mingw32-g++ -g -shared -Wl,-subsystem,windows -Wl,--out-implib,/mnt/hdd/aur/mingw-w64-qt5-base/src/build-i686-w64-mingw32/lib/libQt5Widgets.dll.a -o ../../lib/Qt5Widgets.dll object_script.Qt5Widgets.Release -lcomdlg32 -loleaut32 -limm32 -luuid -ladvapi32 -ljpeg -lpng -L/usr/i686-w64-mingw32/lib -lfreetype -lbz2 -lharfbuzz -lglib-2.0 -lws2_32 -lole32 -lwinmm -lshlwapi -lpcre -lintl -liconv -lgraphite2 -lglu32 -lopengl32 -lgdi32 -luser32 -L/mnt/hdd/aur/mingw-w64-qt5-base/src/build-i686-w64-mingw32/lib /usr/i686-w64-mingw32/lib/libQt5Gui.dll.a /usr/i686-w64-mingw32/lib/libQt5Core.dll.a -lshell32 -luxtheme -ldwmapi
./.obj/release/qdirmodel.o: In function `ZNK16QDirModelPrivate4nameERK11QModelIndex':
/mnt/hdd/aur/mingw-w64-qt5-base/src/qtbase-opensource-src-5.9.2/src/widgets/itemviews/qdirmodel.cpp:1285: undefined reference to `_imp___ZN16QFileSystemEntry10isRootPathERK7QString'
./.obj/release/qdirmodel.o: In function `ZNK9QDirModel8fileNameERK11QModelIndex':
/mnt/hdd/aur/mingw-w64-qt5-base/src/qtbase-opensource-src-5.9.2/src/widgets/itemviews/qdirmodel.cpp:1108: undefined reference to `_imp___ZN16QFileSystemEntry10isRootPathERK7QString'
./.obj/release/qfileiconprovider.o: In function `ZNK17QFileIconProvider4typeERK9QFileInfo':
/mnt/hdd/aur/mingw-w64-qt5-base/src/qtbase-opensource-src-5.9.2/src/widgets/itemviews/qfileiconprovider.cpp:303: undefined reference to `_imp___ZN16QFileSystemEntry10isRootPathERK7QString'
./.obj/release/qfileiconprovider.o: In function `ZNK17QFileIconProvider4iconERK9QFileInfo':
/mnt/hdd/aur/mingw-w64-qt5-base/src/qtbase-opensource-src-5.9.2/src/widgets/itemviews/qfileiconprovider.cpp:252: undefined reference to `_imp___ZN16QFileSystemEntry10isRootPathERK7QString'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile.Release:867: ../../lib/Qt5Widgets.dll] Error 1
make[3]: Leaving directory '/mnt/hdd/aur/mingw-w64-qt5-base/src/build-i686-w64-mingw32/src/widgets'
make[2]: *** [Makefile:36: release] Error 2
make[2]: Leaving directory '/mnt/hdd/aur/mingw-w64-qt5-base/src/build-i686-w64-mingw32/src/widgets'
make[1]: *** [Makefile:627: sub-widgets-make_first] Error 2
make[1]: Leaving directory '/mnt/hdd/aur/mingw-w64-qt5-base/src/build-i686-w64-mingw32/src'
make: *** [Makefile:45: sub-src-make_first] Error 2
==> ERROR: A failure occurred in build().
Aborting...

Updated to 5.9.2. I also fixed qmake so it now links against static plugins by default when using the static variant. This didn't work (anymore) because of our way to merge shared and static builds. However, this revealed further bugs:
* qmake is messing dependency cycle of static freetype and harfbuzz. This can be worked around by adding `CONFIG+=no_smart_library_merge` to qmake arguments.
* qmake does not include dependencies of static Qt modules when only linking against a plugin which pulls that Qt module but not using the module itself explicitly. Just link against the module explicitly by adding `QT+=the_module` to qmake arguments.
* The Qt Network module can not be used with the static MySQL plugin because the plugin's its dependency mariadb-connector-c uses OpenSSL 1.1 while Qt is still using OpenSSL 1.0. Both versions can not be combined. Qt 5.10 will fix this by supporting OpenSSL 1.1.

BTW: If you need Qt location but not the included mapbox-gl plugin, I suggest disabling this feature as it requires a lot of time to compile. The binaries provided at my repository will not include the plugin anymore (for now).

> As i said, i have missing references in libQt5Widgets.a(qwindows{vista|xp}style.o) and libQt5Gui.a(qopenglpaintengine.o).

I need the cmake/qmake call, the compiler/linker line which fails and the error output. Otherwise I can just do some guessing.

> I noticed that neither qopenglpaintengine.a nor qwindows*.a files exist in mingw-w64-qt5-base-static, but i guess i need them at compile-time?

If you believe some files are missing in your mingw-w64-qt5-base-static packages, just download the one from my repository (linked in the pinned comment) and compare the files. Note that the mentioned libraries are 'static plugins', so they are in an extra subdirectory (this is not Windows specific at all). Eg. libqwindows.a should be located under /usr/x86_64-w64-mingw32/lib/qt/plugins/platforms/libqwindows.a. You need those files at compile time, if you want to use them (you very likely want the platform integration plugin).

Note that this package also contains symlinks for the static plugins eg. /usr/x86_64-w64-mingw32/lib/libqwindows.a, but this shouldn't actually be required (just some precaution to prevent errors in case of plugin path is missing).

> As the static libQt5*.a files only contain the references?
The libQt5*.a libraries should not contain any references to the plugins. The plugins are optional additions loaded via dlopen (or similar under Windows) or in case of the static variant 'optionally built-in'. In the latter case the actual application must contain the references (eg. via http://doc.qt.io/qt-5/qtplugin.html#Q_IMPORT_PLUGIN).

Thanks for your help!

I applied the patch you linked.
Unfortunately, i can't get it to work, i still have the linking problems with the windows-stuff...
I'm really not well-versed, so please bear with me :)
As i said, i have missing references in libQt5Widgets.a(qwindows{vista|xp}style.o) and libQt5Gui.a(qopenglpaintengine.o).
I noticed that neither qopenglpaintengine.a nor qwindows*.a files exist in mingw-w64-qt5-base-static, but i guess i need them at compile-time?
As the static libQt5*.a files only contain the references?
But why does dynamic linking then work, when mingw-w64-qt5-base too does not contain these files?
Have they maybe been created while building the mingw-packages and linked into the .dll's, but not copied over or built when composing the static package?

I guess i'll wait for the next update, this seems to go far beyond my understanding...

@hein09 I found a workaround. See my previous comment for an answer to your last question and what the related problems are (if you haven't read it yet).

It seems the issue that qmake is messing dependency cycle between freetype2 and harfbuzz can be easily worked around by simply adding `no_smart_library_merge` to the config. No need to recompile anything. Maybe I better keep 0030-Prevent-qmake-from-messing-static-lib-dependencies.patch for CMake.

So the following works for me:
```
pacman -Syu qt5-examples
cd some/empty/directory
x86_64-w64-mingw32-qmake-qt5 CONFIG+=static CONFIG+=no_smart_library_merge /usr/share/doc/qt/examples/widgets/mainwindows
make -j4
wine mainwindow/release/mainwindow.exe
```

No linker errors. And when applying https://github.com/Martchus/qtbase/commit/acc61ef7833f685b1f66c9b99086ccfc1e6aa20f `mainwindow.exe` even has the windows platform plugin built-in. Only drawback is that the linker line is now quite long (but g++ seems to handle it without problems).

(Instead of rebuilding everything, you can also do the changes of https://github.com/Martchus/qtbase/commit/acc61ef7833f685b1f66c9b99086ccfc1e6aa20f in your local installation. I'll add the patch with the next update.)

@hein09
I don't remember the purpose so I'll just drop it in the next update. However, when something explicitly supports Windows, this might not necessarily include cross compilation with mingw-w64 (which is not supported by upstream).

> What should trigger this automatic adding?

If you're using CMake, nothing will pull those dependencies if you omitted patch 0023-Allow-usage-of-static-version-with-CMake.patch.
(BTW, this monster patch will be spitted in next update, see https://github.com/Martchus/qtbase/commits/5.9.1-mingw-w64)

If you're using qmake, some qmake internal magic triggers adding those dependencies. However, it seems to mess things up under certain conditions. At least the cyclic dependency between harfbuzz and freetype2 is not handled correctly. Hence I disabled this when building static libraries (see 0030-Prevent-qmake-from-messing-static-lib-dependencies.patch). However, when building/linking the final application it is still enabled (unless you use `CONFIG+=staticlib`). This way the static library dependencies are at least preserved for CMake so building a statically linked application using CMake works.

When building with qmake you'll unfortunately either get linker errors about freetype2/harfbuzz (if you don't add `CONFIG+=staticlib`) or get linker errors about other missing dependencies not explicitly mentioned in the mkspec (iconv, but also dependencies of the plugins).

Those problems with qmake are currently not preventing mingw-w64-qt5-tools to build because linking against static plugins with qmake is broken anyways and hence the freetype2/harfbuzz issue does not seem to occur.

BTW: If you're wondering why it links against pcre *and* pcre2, the reason is that Qt recently switched to version 2 but pcre is still pulled by harfbuzz for glib2.

To summarize: The static variant only works with CMake correctly.
1. Linking against static plugins with qmake needs to be fixed. It is currently simply not done. This is caused by 0022-Merge-shared-and-static-library-trees.patch. Fixing it should be quite easy: https://github.com/Martchus/qtbase/commit/acc61ef7833f685b1f66c9b99086ccfc1e6aa20f
2. But this leads to the next problem. The dependency cycle between freetype2 and harfbuzz must be handled correctly by qmake. The patch 0030-Prevent-qmake-from-messing-static-lib-dependencies.patch is only sufficient for CMake. To make qmake work when 1. has been fixed, qmake must be improved to handle the dependency cycle between freetype2 and harfbuzz.

So I'm not sure why iconv isn't added in your case. It should be if your config doesn't contain `staticlib` which should not be the case by default. But if you want to link against static plugins (which is likely the case when doing a static build) you're currently not coming very far with qmake anyways.