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
