If the libcxx headers already have been installed, adding
-I$LIBCXX/include to the include path breaks some C standard
headers. The libcxx installation provides e.g. stdlib.h, which
does an #include_next <stdlib.h>. If the include path includes
both $LIBCXX/include and the libcxx headers installed to the
target sysroot, the #include_next will pick up the same header
from the next include directory. And due to include guards,
the second inclusion of the libcxx version of the header does
nothing at all, instead of doing yet another #include_next for
picking up the real version of the header.
By adding -nostdinc++, we avoid the possibly installed version
of these headers.
This fixes rebuilding libunwind after libcxx has been built
and installed.
This version of mingw-w64 provides a few more import libraries
for aarch64, and allows using a lot more uncommon stdio functions
with ucrtbase.
The new libcxx version allows forcing using win32 threads even
if pthread.h exists.
The MinGW CRT wrapping has a few minor issues that makes native
TLS fail at the moment.
LLVM doesn't support native TLS on windows/aarch64, but emulated
TLS is supported now.
This includes support for a -fdwarf-exceptions flag in clang,
allowing to choose that exception handling model on architectures
where it isn't the default.
This avoids having to manually add -lpsapi when linking in libc++.a.
This requires using a new script to merge libraries using ar -M
with a small MRI script.
The script merge_archives.py in libcxx does the merge by manually
extracting all object files and creating a new archive out of them.
The import libraries created by LLVM have more than one object file
with the same file name (just like MSVC tools do), so extracting
them doesn't work as intended - but merging using a MRI script works.
This is the correct layering/ordering.
This requies setting forcing CXX_SUPPORTS_CXX11=TRUE in cmake,
since it tries linking to see whether the C++ environment works,
but we haven't built libcxx yet.
Manually add the libcxx include directory to the include path
(since libunwind does use some C++ headers but doesn't require
linking to C++ libraries).
Dwarf is also the default in clang on i686, but libunwind currently
has an issue relating to unwinding dwarf exceptions on i686 on
windows (and less easily reproducible on other platforms),
see https://reviews.llvm.org/D38680.
This enables exceptions on aarch64, where they previously were
avoided/disabled.
When linking to a statically linked libunwind with support for
dwarf, one (currently) has to link in -lpsapi.
Martin Storsjö