Hello Martin. 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`. I can add condition that this workaround will be applied only when MinGW is being built with GCC and only when `libgcc` is available. How would you detect the scenario when `mingw-w64-crt` is being built for the future use with `mingw-w64-crt/winpthreads`?
Radek ________________________________________ From: Martin Storsjö <mar...@martin.st> Sent: Wednesday, March 26, 2025 1:29 PM To: Radek Barton via Mingw-w64-public <mingw-w64-public@lists.sourceforge.net> Cc: Radek Barton <radek.bar...@microsoft.com> Subject: [EXTERNAL] Re: [Mingw-w64-public] [PATCH] Add `-mno-outline-atomics` to `CFLAGS`` when building `mingw-w64-crt` and `mingw-w64-libraries/winpthreads` for `aarch64-*` On Tue, 25 Mar 2025, Radek Barton via Mingw-w64-public wrote: > As a follow up to the first patch "[PATCH] Add check if `libgcc` is available > and link `winpthreads` against it instead of `fakelib`" I am sending another > possibility how to overcome the undefined references of to outline atomics > LSE intrinsic functions for `aarch64-w64-mingw32` GCC build that adds > `-mno-outline-atomics` flag to build of `mingw-w64-crt` and > `mingw-w64-libraries/winpthreads`. Note that the flag is required for both > libraries. > > --- > mingw-w64-crt/Makefile.am | 1 + > mingw-w64-libraries/winpthreads/Makefile.am | 1 + > mingw-w64-libraries/winpthreads/configure.ac | 7 +++++++ > 3 files changed, 9 insertions(+) I don't oppose this change. But the commit message does need to be written so that it is understandable on its own, not referencing the previous patch. (If committed, the commit will be read and studied in isolation long in the future - so it does need to explain the whole rationale of the situation.) It also needs to clearly state that this is to work around issues with the circular dependencies between winpthreads and libgcc. If building with e.g. compiler-rt instead of libgcc, there's no such circular dependency. Compiler-rt's builtins only exist in static form, and they don't depend on any third party libraries, so there's a very clear and consistent layering between these libraries. With compiler-rt, there's currently no problems in building mingw-w64-crt and winpthreads with -moutline-atomics. Also likewise, if libgcc is configured to not use winpthreads as internal threading library (e.g. if building with the win32 thread model, which is quite capable these days), then winpthreads wouldn't need to use its fake libgcc at all; one would just build winpthreads as a regular user library after the toolchain (including the proper libgcc) has been built. So I'm ok with applying this patch - but it's pointing out that it is spreading a workaround that only specific configurations really need. (If we consider a future where libgcc using winpthreads would be less common, we should maybe consider if winpthreads should detect that kind of configuration, somehow, and stop using the fake libgcc unless winpthreads will be a libgcc dependency.) // Martin _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
