Analysis of Broken Windows Static Building + Fix

[1ahmadbassam]

qBittorrent & operating system versions

qBittorrent: 5.0.3/5.1.0beta1 x64
Operating system: Windows + MSVC 2019 v16.11.42; Applies to all Windows builds but I personally tested it on Windows 7 SP1
Qt: 6.8.1
libtorrent-rasterbar: 2.0.10
OpenSSL: 3.4.0
Boost: 1.87
zlib: 1.3.1

What is the problem?

Windows static builds were broken in the transition to Qt6, version 5 of qBittorrent. This was first seen in issue #20805.
I have read around and it seems like it was not known why at the time. I have taken my time to properly debug the issue to determine the problem. I present my findings below.

Steps to reproduce

1. Coroutine ABI Mismatches

Apparently, the latest versions of prebuilt boost are compiled with "/await:strict" MSVC compiler option which enables the new C++-20 like coroutines. Qt6 also uses coroutines but they are compiled with the standard coroutine ABI. This causes a conflict between them.
I'm going to leave more information about the mismatch to Raymond Chen over at Microsoft.
To solve this issue properly, Qt6 needs to be compiled from source with the "/await:strict" compiler option. For example, I built it like this:

C:\Qt\6.8.1\src_min\configure.bat -prefix C:\Qt\6.8.1\msvc2019_64_static_min_cr -release -static -static-runtime -accessibility -no-icu -no-sql-psql -no-sql-sqlite -no-qml-debug -nomake examples -nomake tests -platform win32-msvc -openssl-linked -- -DCMAKE_CXX_FLAGS="/await:strict"  -DOPENSSL_ROOT_DIR="C:\Libs\openssl-3.4.0-w64" -DOPENSSL_INCLUDE_DIR="C:\Libs\openssl-3.4.0-w64\include" -DOPENSSL_USE_STATIC_LIBS=ON -DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreaded -DCMAKE_POLICY_DEFAULT_CMP0091=NEW -Wno-dev 

Alternatively, the dev blogs state we can use _ALLOW_COROUTINE_ABI_MISMATCH preprocessor directive to disable the check. I have not tried it and it is not recommended since Boost and Qt will, most likely, conflict.

2. Redefinition of symbols

Apparently, some symbols in the Qt6 lib cannot link normally because qBittorrent's libs linked them first. I think this is an issue with the linking order, but I saved myself the hassle by building qBittorrent with -DCMAKE_EXE_LINKER_FLAGS="/FORCE:MULTIPLE" to allow the linker to accept multiple definitions for the same symbol (they originate from the same place, so it is fine).

Essentially my build configuration command is like this:

cmake -B "temp\build" -S "%QBITTORRENT_SRC%" -G "Ninja" -Wno-dev -DCMAKE_CXX_FLAGS="/DQT_FORCE_ASSERTS /WX" -DCMAKE_BUILD_TYPE=Release -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DMSVC_RUNTIME_DYNAMIC=OFF -DBOOST_ROOT="%BOOST_ROOT%" -DCMAKE_EXE_LINKER_FLAGS="/FORCE:MULTIPLE" -DCMAKE_INSTALL_PREFIX="%CD%\temp\upload" -DLibtorrentRasterbar_DIR="%CD%\temp\deps\lib\cmake\LibtorrentRasterbar"  -DCMAKE_PREFIX_PATH="%QT_ROOT%;%CD%\temp\deps" -DOPENSSL_ROOT_DIR="%OPENSSL_ROOT%" -DOPENSSL_INCLUDE_DIR="%OPENSSL_ROOT%\include" -DOPENSSL_USE_STATIC_LIBS=ON -DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreaded -DCMAKE_POLICY_DEFAULT_CMP0091=NEW --graphviz=temp\build\target_graph.dot 

Additional context

Once these changes are authored, qBittorrent links statically just fine. The image below shows qBittorrent 5.1.0beta1 linked statically and working as it should.

For the CI, if static builds are to be reimplemented, the best solution is probably to build Qt6 from source in the CI with "/await:strict" option. This will increase building times but will solve the issue. The coroutine mismatch is not a qBittorrent issue, it's just a mismatch between Qt6 and Boost.

Log(s) & preferences file(s)

No logs needed