Skip to content

Add MinGW (Windows GNU) toolchain support#1396

Open
GuyFromTheInternet wants to merge 2 commits into
KDAB:mainfrom
GuyFromTheInternet:mingw-support
Open

Add MinGW (Windows GNU) toolchain support#1396
GuyFromTheInternet wants to merge 2 commits into
KDAB:mainfrom
GuyFromTheInternet:mingw-support

Conversation

@GuyFromTheInternet

@GuyFromTheInternet GuyFromTheInternet commented Jan 23, 2026

Copy link
Copy Markdown

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:

  • crates/cxx-qt/src/init.cpp - Use Q_COREAPP_STARTUP_FUNCTION (Qt5 only)
  • crates/cxx-qt-lib/src/core/init.cpp - Use Q_COREAPP_STARTUP_FUNCTION
  • crates/cxx-qt-lib/src/gui/init.cpp - Use Q_COREAPP_STARTUP_FUNCTION
  • crates/cxx-qt-build/src/lib.rs - Use atomic operations for initialization

Tested with Qt 6.8.3 MinGW build on Windows 11 using x86_64-pc-windows-gnu target.

@GuyFromTheInternet GuyFromTheInternet marked this pull request as draft January 24, 2026 01:25
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.
@GuyFromTheInternet GuyFromTheInternet marked this pull request as ready for review January 24, 2026 02:30

@ahayzen-kdab ahayzen-kdab left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@ahayzen-kdab

Copy link
Copy Markdown
Collaborator

And guess there might need to be a Rust toolchain installed too, so might need to be an additional entry for that

@GuyFromTheInternet

Copy link
Copy Markdown
Author

Pretty sure I did everything you asked

@codecov

codecov Bot commented Feb 23, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (55106f0) to head (ed42b48).
⚠️ Report is 13 commits behind head on main.

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.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

Comment on lines +565 to +568
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

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note when rebasing this that we've moved onto Rust 1.85.0, this may help with some of the errors too

Comment on lines +1144 to +1146
declaration = declaration,
init_call = call,
key = key,

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

are these even needed when the format! line has {key} does it not pick those up without needing to specify after?

Comment on lines 1106 to +1119
@@ -1128,7 +1116,7 @@ extern "C" bool {init_fun}() {{
)
.files(
private_initializers
.into_iter()
.iter()

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Comment on lines +122 to 128
extern "C" bool
init_cxx_qt_lib_core()
{
// Registration is handled automatically via Q_COREAPP_STARTUP_FUNCTION
// when QCoreApplication is constructed.
return true;
}

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants