mingw-w64-clang-x86_64-qt6-static has dynamic dependencies

[DragonCrafted87]

using the static build of qt6 to build a static release executable

the resulting binary reports the following missing dlls when ran on a clean windows 10 machine

libmng-2.dll libpcre2-16-0.dll libtiff-5.dll libjasper-4.dll

there are probably others as the app I am using to setup my build only really touches qt core and widgets libraries

[foxoman]

I can confirm this , can not build qt6 static not with qmake nor with cmake

[youngbe]

I confirm too. Up to now, still need libjasper-4.dll and libjpeg-8.dll.

[Nnarol]

I tried with mingw32/mingw-w64-i686-qt6-static 6.2.1-2, and there were still at least two:

libb2 libjasper

My installation was not clean, but I changed the makefile to pass the -t option to ld (-Wl,-t to g++) so it prints all input files with full path, and there were no ".so" files present. Even those linked with -l, like -lwebpdemux, resolve to a static ".a" library.

[Biswa96]

The main hurdle is that CI can not compile the qt static package due to the size of it. One package maintainer has to dedicate an entire day for it.

[Nnarol]

Oh, so that's what's happening! Thanks for the explanation, @Biswa96!

Would it be possible to divide the distributed library into its original architectural modules (EDIT: https://doc.qt.io/qt-6/qtmodules.html) or into larger module groups? That way, people could install e.g. qt6-core-static, qt6-widgets-static or, using a less granular approach, qt6-base-static, qt6-extension1-static, etc.?

As an alternative, since a static library is just an archive of different objects or sublibraries, could individual components not be tested by the CI instead of the actual, distributed package while there is a proper solution? Although that way, CI tests would not match the system in production, but they would be an approximation. The current state is buggy anyway.