On Wed, 26 Mar 2025, Radek Barton wrote:
Thank you for your feedback. That message was not intended to be a commit message but message of context for the reviewers. I cannot use `git send-patch` but next time I'll copy and paste the entire output of `git format-patch` including the first part where I'll mention that the change is a workaround for `libgcc`.
Ok, thank you!
I can add condition that this workaround will be applied only when MinGW is being built with GCC and only when `libgcc` is available.
Thanks, that would reduce the impact on my toolchains even further (allowing me to switch to outline atomics throughout the whole stack, if I wanted to). But you probably can't do it for "GCC + libgcc available", because early in the toolchain bootstrap, you don't have libgcc available yet. But limiting it to when building with GCC, probably is reasonable, and limits the scope of the workaround further.
How would you detect the scenario when `mingw-w64-crt` is being built for the future use with `mingw-w64-crt/winpthreads`?
That's the really tricky part. :-) It's probably quite ugly; it may be possible to parse the output of "$CC -v", where GCC prints "Thread model: posix" when configured to use winpthreads within libgcc. But doing that also requires distinguishing between GCC and Clang, because Clang always prints "Thread model: posix" without any correlation to how anything is configured.
I'm not 100% suggesting we should do this, but I'm opening it up for discussion whether others think it would be useful. As doing that would entirely get rid of the circular dependency.
// Martin _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
