The checks behind LLVM_COMPILER_CHECKED fail if there's no libc++
available for linking.
This fixes building libunwind/libcxxabi/libcxx with newer versions
of llvm, if the llvm installation isn't stripped.
Some libcxxabi source files define _LIBCPP_BUILDING_LIBRARY themselves.
A "#define FOO" in a file defines it to "", while "-DFOO" on the command
line defines it to "1". Define it on the command line using "-DFOO=" to
make it match the #define within the source files.
This reverts commit 92f301f775.
With the latest versions of libunwind and libcxxabi, the -w option
for suppressing compiler warnings isn't added any longer when building
with the llvm cmake files available.
The DLL build fails since we stopped setting LIBCXX_ABI_UNSTABLE=TRUE,
if the tests are enabled (which they are if building against a
non-stripped llvm installation).
This version supports SEH for arm64, fixes certain cases of dllexport
of C++ classes defined entirely in headers (fixing building Qt in
debug mode), and fixes a compiler bug (regression since the end of
August 2018) when compiling glslang (as part of VLC) for armv7.
This didn't seem to actually be necessary, not even in the initial
commit adding support for building a DLL of libcxx. It might have
been necessary at some earlier point while working on building a DLL.
This is set via a cmake option when building libcxx, but libcxxabi
uses the raw libcxx headers from its include directory before they
are installed.
This fixes cases of inconsistent classes seen while compiling libcxxabi
and libcxx. With potential future patches to clang to adjust how
classes are exported with dllexport, this change is needed to avoid
conflicts.
If the triplet directory is wiped and only the build-mingw-w64.sh
step is rerun, the bin subdirectory would be missing, ending up
with a file named "bin", which actually was the libc++ DLL.
This option seems to be used occasionally by projects to work around
various issues with popen in GNU windres.
Our windres wrapper always uses a temp file for the preprocessing
output, so for us the option is a no-op.
Convert paths with backslashes to forward slashes.
libtool tries to parse this output in order to find object files and
libraries that always should be linked in, but libtool can't handle
paths with backslashes (and quotes) which clang currently outputs.
This is a quick and ugly workaround until clang can be made to
output paths with forward slashes on windows, see
https://reviews.llvm.org/D53066 for progress on that matter.
Martin Storsjö