On Thu, 14 Jan 2021, Martin Storsjö wrote:
On Wed, 13 Jan 2021, Jeremy Drake wrote:
On Wed, 13 Jan 2021, Martin Storsjö wrote:
The pragmatic path forward in that case, I think, would to add a configure
option to mingw-w64-crt for optionally enabling the __cxa_thread_atexit
function. So if that's omitted from mingw-w64-crt, a new build of
libstdc++
would include their version of it instead, and it should work as it used
to,
for better and worse.
For my llvm-mingw builds, I'd enable it, as the mingw implementation of
__cxa_thread_atexit is highly windows specific, and I pretty much doubt
that
libcxxabi would be willing to integrate there. Just like on other
platforms,
the C runtime level layer provide the platform specific hooks for
implementing
the feature.
Something just occurred to me: what about the clang packaged in msys2? I
believe it defaults to using libstdc++, but I think it does also provide
libc++ as an option. If the msys2 project selects crt options that work
for gcc/libstdc++, will that preclude using the same crt build with
clang/libc++?
I think (but haven't checked in detail) that such a setup of libc++ runs on
top of the "cxxabi" bits from libstdc++/libsupc++, so in such a case it
wouldn't matter - it only matters for totally standalone setups of libc++,
where it's layered on top of libcxxabi instead.
It can very well be the case that msys2's builds of libcxx are on top of
libcxxabi even in the regular gcc based sysroots.
What about patching upstream gcc/libstdc++ to add an option for preferring
to provide its own __cxa_thread_atexit even if the platform seems to have
one? Ideally it'd default to enabled for mingw platforms.
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
