Since the default _WIN32_WINNT now is for Windows 7, psapi.h
redirects to PSAPI version 2, which is available in kernel32.dll
with a "K32" prefix on the function names (K32EnumProcessModules).
This updates compiler-rt, libunwind, libcxxabi and libcxx to a newer
version, matching the compiler.
This will be the official, canonical repo in the future.
For the non-dev Dockerfile build, this means that all the llvm based
subprojects need to be built in one RUN to avoid storing the llvm
checkout in the docker layers.
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 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 fixes potential pointer truncation on 64 bit windows.
(Existing tests have ran fine in practice; either these are codepaths
not exercised in current setups, or potential codepaths that could
be triggered with more extensive tests.)
For compiler-rt and libunwind, this makes them build successfully even
if llvm-config and the llvm cmake files aren't available.
For libcxxabi, this brings in support for using SEH exceptions.
For libcxx, this removes a few build time warnings.
When building libcxx, this is also already enabled via the cmake
option -DLIBCXX_HAS_WIN32_THREAD_API=ON.
This fixes building libcxxabi if pthreads are available.
As long as we pass --sysroot explicitly in clang-target-wrapper.sh,
this isn't necessary. And since clang SVN r329946. it's no longer
necessary when not specifying the sysroot (and having it is in
fact harmful).
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.
Martin Storsjö