Add MinGW (Windows GNU) toolchain support#1396
Conversation
Use Q_COREAPP_STARTUP_FUNCTION for metatype registration, which is Qt's recommended approach and works reliably on all platforms including MinGW. Change generated initializer code to use atomic operations instead of std::call_once for simpler, more portable initialization.
39a3220 to
c042786
Compare
ahayzen-kdab
left a comment
There was a problem hiding this comment.
Awesome! Thanks for looking at solving this!
Looks like CI is failing as clang-format needs to run over the files, are you able to do that?
And then would you be comfortable attempting to add a CI runner for this? As it would be good to ensure we do not regress and we can prove that it works.
This would be a matter of adding MinGW to the matrix similar to MSVC here (can be release rather than debug) https://github.com/KDAB/cxx-qt/blob/main/.github/workflows/github-cxx-qt-tests.yml#L394 set the values in the matrix, eg likely it is win64_mingw as the aqt_arch, then check if any other runner.os == 'Windows' need updating/changing. And note only do this for Qt 6, don't both with Qt 5.
|
And guess there might need to be a Rust toolchain installed too, so might need to be an additional entry for that |
4d297f5 to
ed42b48
Compare
|
Pretty sure I did everything you asked |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1396 +/- ##
==========================================
Coverage 100.00% 100.00%
==========================================
Files 75 75
Lines 13124 13457 +333
==========================================
+ Hits 13124 13457 +333 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| rustup toolchain install 1.77.2-x86_64-pc-windows-gnu | ||
| rustup toolchain install 1.78.0-x86_64-pc-windows-gnu --component clippy | ||
| rustup default 1.77.2-x86_64-pc-windows-gnu | ||
| rustup component add rustfmt |
There was a problem hiding this comment.
note when rebasing this that we've moved onto Rust 1.85.0, this may help with some of the errors too
| declaration = declaration, | ||
| init_call = call, | ||
| key = key, |
There was a problem hiding this comment.
are these even needed when the format! line has {key} does it not pick those up without needing to specify after?
| @@ -1128,7 +1116,7 @@ extern "C" bool {init_fun}() {{ | |||
| ) | |||
| .files( | |||
| private_initializers | |||
| .into_iter() | |||
| .iter() | |||
There was a problem hiding this comment.
Where is the change that means that it is iterated multiple times? Looks like it could be how it was originally still as private_initializer is not used after this?
| extern "C" bool | ||
| init_cxx_qt_lib_core() | ||
| { | ||
| // Registration is handled automatically via Q_COREAPP_STARTUP_FUNCTION | ||
| // when QCoreApplication is constructed. | ||
| return true; | ||
| } |
There was a problem hiding this comment.
does this function need to refer to do_register_core_types to avoid the compiler/linker optimising out the unused method or is it picked up from elsewhere ? As this was a problem before when the static lib is made and then linked to the app
This PR adds support for building cxx-qt applications with the MinGW (x86_64-pc-windows-gnu) toolchain on Windows.
Changes:
Started using Q_COREAPP_STARTUP_FUNCTION for metatype registration, the previous implementation used std::call_once for one-time metatype registration during static initialization. This fails on MinGW because the pthread TLS emulation (_emutls*) used by MinGW's std::call_once implementation isn't initialized during static constructors, causing a crash.
I also use atomic operations for initialization guards since this is simpler, has no TLS dependencies and works correctly on all platforms including MinGW.
Files changed:
Tested with Qt 6.8.3 MinGW build on Windows 11 using x86_64-pc-windows-gnu target.