Arch Linux User Repository

FAQ:

Should this depend on the mingw-w64-qt6-base package?

No, it should not. The Qt 5 packages had a "merged" installation of shared and static libraries within the same installation prefix. That was possible due to patches from Fedora which the previous package maintainer added. However, it was never supported by upstream and I had to add my own patches and adjustments over time to keep it working. Hence I ditched the "merged" installation approach for Qt 6 which means the shared and static variants are completely independent from each other and the static variant is installed within a nested install prefix to avoid conflicts.

Also, it seems find_package(Qt6 COMPONENTS Widgets) with USE_STATIC_QT_BY_DEFAULT results in an error upon running cmake

Please note that USE_STATIC_QT_BY_DEFAULT is part of the mentioned patches for Qt 5 and does not apply to Qt 6. To use the static Qt 6 version, simply prepend its install prefix to CMAKE_FIND_ROOT_PATH. I've also created https://aur.archlinux.org/packages/mingw-w64-cmake-static which eases linking statically against all dependencies. I've been using it successfully for my own projects, e.g. https://github.com/Martchus/PKGBUILDs/blob/master/syncthingtray/mingw-w64-qt6/PKGBUILD. (Of course it won't work if not all of your dependencies are available as static libraries.)

This means that it is no longer possible to use the shared and static version of Qt within the same build/configuration (e.g. to build a dynamically linked and a statically linked application in one go) as you would run into errors like the one you've just got. Sorry for that but it was just too much of a hassle to support (considering it only worked due to my own patches with no support from upstream).

Also see https://github.com/Martchus/PKGBUILDs#brief-documentation-about-mingw-w64-qt-packages

• Further notes: https://github.com/Martchus/PKGBUILDs#brief-documentation-about-mingw-w64-qt-packages
• Binary repository: https://martchus.no-ip.biz/repo/arch/ownstuff, https://wiki.archlinux.org/index.php/Unofficial_user_repositories#ownstuff
• All my packages are managed at GitHub where you can also contribute directly: https://github.com/Martchus/PKGBUILDs

Yeah you are right, static linking is a second class citizen in many of these build systems and it would take a lot to change that at a packaging level.

For all my Qt packages I'm using a template system anyways so generating separate static packages is not much extra effort. However, for other packages it would be quite some effort to keep packages in sync. The migration effort would be quite high as well. I don't think it is worth the effort, especially not for projects where the build system supports building shared and static libraries in one go (which is not the case for Qt 5 and Qt 6 by the way).

I would like to note that splitting packages and installing static libraries in their own prefix does not magically solve all the issues. The build system of Qt 5 will still not be able to deal with static libraries without heavy patching because it is just too broken on its own. The build system of Qt 6 and other projects will also still require some patching and workarounds because still not everything is perfect. I've had to realize that recently when working on static-compat packages. For instance, brotli still produces a wrong pkgconfig file, some CMake find modules (e.g. used by Qt) still don't track static dependencies correctly, some still need special configuration (BOOST_USE_STATIC_LIBS=ON) and also projects using Meson needed hacks like export LDFLAGS='-l…. So while things get a little cleaner the huge effort would by no means make all patches and hacks unnecessary. That's why I would come to the conclusion that it is not generally worth it.

By the way, mingw-w64-cmake-static should fix all¹ issues for CMake-based projects making static builds quite easy. Of course https://aur.archlinux.org/cgit/aur.git/tree/toolchain-mingw-static.cmake?h=mingw-w64-cmake-static is quite hacky but at least all those general hacks are at one place and reusable.

¹ Everything needed by Qt, Boost and a few other libs at least. If you try to build other things you may still be out of luck. However, that's usually simply because no static libraries exist in the package because the projects' build systems don't allow to build both versions at the same time or static libraries are generally not supported by upstream (e.g. GTK and some related projects don't support static libs). For those packages a separate -static variant would make sense as far as it is possible. Some upstream limitations might be fixed with additional patching like I did for the Qt packages. The static variant could then also be configured with less/other dependencies if that's needed, e.g. ffmpeg could use OpenSSL instead of GnuTLS (which is when I remember also one of those projects not supporting static libs).

Kind of unrelated to this package, but how feasible is it to completely refactor all AUR mingw packages to use the same /static prefix as this package? The current way most packages provide static libs requires using pig disgusting hacks project-side to get everything to link properly, having everything do what this package does would be so much easier. The de facto standard of installing a shared build directly over top of static builds does not work in practice.

The problem here is getting all package maintainers to agree on this. I only hold a couple of mingw packages myself but I can try and get maintainer status of more as a few I use seem to be abandoned.

The other option is to do somewhat of a hostile takeover and create -static packages for various libraries since those package names are not taken on the AUR, then drop static libs from the shared packages we control. I'm just at my wits end dealing with linker errors caused by horrible dependency discovery.

FAQ:

Should this depend on the mingw-w64-qt6-base package?

No, it should not. The Qt 5 packages had a "merged" installation of shared and static libraries within the same installation prefix. That was possible due to patches from Fedora which the previous package maintainer added. However, it was never supported by upstream and I had to add my own patches and adjustments over time to keep it working. Hence I ditched the "merged" installation approach for Qt 6 which means the shared and static variants are completely independent from each other and the static variant is installed within a nested install prefix to avoid conflicts.

Also, it seems find_package(Qt6 COMPONENTS Widgets) with USE_STATIC_QT_BY_DEFAULT results in an error upon running cmake

Please note that USE_STATIC_QT_BY_DEFAULT is part of the mentioned patches for Qt 5 and does not apply to Qt 6. To use the static Qt 6 version, simply prepend its install prefix to CMAKE_FIND_ROOT_PATH. I've also created https://aur.archlinux.org/packages/mingw-w64-cmake-static which eases linking statically against all dependencies. I've been using it successfully for my own projects, e.g. https://github.com/Martchus/PKGBUILDs/blob/master/syncthingtray/mingw-w64-qt6/PKGBUILD. (Of course it won't work if not all of your dependencies are available as static libraries.)

This means that it is no longer possible to use the shared and static version of Qt within the same build/configuration (e.g. to build a dynamically linked and a statically linked application in one go) as you would run into errors like the one you've just got. Sorry for that but it was just too much of a hassle to support (considering it only worked due to my own patches with no support from upstream).

Also see https://github.com/Martchus/PKGBUILDs#brief-documentation-about-mingw-w64-qt-packages

Should this depend on the mingw-w64-qt6-base package?

Also, it seems find_package(Qt6 COMPONENTS Widgets) with USE_STATIC_QT_BY_DEFAULT results in an error upon running cmake

CMake Error at /usr/x86_64-w64-mingw32/lib/cmake/Qt6Core/Qt6CoreVersionlessTargets.cmake:37 (message):
  Some (but not all) targets in this export set were already defined.

  Targets Defined: Qt::Core

  Targets not yet defined: Qt::CorePrivate

Call Stack (most recent call first):
  /usr/x86_64-w64-mingw32/lib/cmake/Qt6Core/Qt6CoreConfig.cmake:53 (include)
  /usr/share/cmake-3.22/Modules/CMakeFindDependencyMacro.cmake:47 (find_package)
  /usr/x86_64-w64-mingw32/lib/cmake/Qt6/QtPublicDependencyHelpers.cmake:14 (find_dependency)
  /usr/x86_64-w64-mingw32/lib/cmake/Qt6Widgets/Qt6WidgetsDependencies.cmake:91 (_qt_internal_find_dependencies)
  /usr/x86_64-w64-mingw32/lib/cmake/Qt6Widgets/Qt6WidgetsConfig.cmake:40 (include)
  /usr/x86_64-w64-mingw32/lib/cmake/Qt6/Qt6Config.cmake:177 (find_package)
  CMakeLists.txt:15 (find_package)


CMake Warning at /usr/x86_64-w64-mingw32/lib/cmake/Qt6/Qt6Config.cmake:177 (find_package):
  Found package configuration file:

    /usr/x86_64-w64-mingw32/lib/cmake/Qt6Widgets/Qt6WidgetsConfig.cmake

  but it set Qt6Widgets_FOUND to FALSE so package "Qt6Widgets" is considered
  to be NOT FOUND.
Call Stack (most recent call first):
  CMakeLists.txt:15 (find_package)

Performing the same steps with Qt5 works.

• Further notes: https://github.com/Martchus/PKGBUILDs#brief-documentation-about-mingw-w64-qt-packages
• Binary repository: https://martchus.no-ip.biz/repo/arch/ownstuff, https://wiki.archlinux.org/index.php/Unofficial_user_repositories#ownstuff
• All my packages are managed at GitHub where you can also contribute directly: https://github.com/Martchus/PKGBUILDs