This reverts commit bd9e16f732.
It turns out this actually isn't needed; since switching to
building via the llvm-project/runtimes directory (in
7b1d05f545), the cmake build
pulls in HandleLLVMOptions.cmake, which checks for and adds
-ffunction-sections and -fdata-sections if supported. Therefore,
we don't need to specify it manually at all.
This reverts parts of commit e35ef3b7d7.
This is now handled better upstream, since
7af584ed87cc6eddb6adbc451c90fb8867469e06 in llvm-project
(November 5th 2021).
Since a8d15a926689c126c4d316788786e0160cfc1d5d in llvm-project
(October 5th), libcxx stopped autodetecting pthreads on mingw,
making pthreads opt-in instead of opt-out.
LLVM's default host detection doesn't always work (cmake doesn't
detect and provide the target architecture, but it provides the
bitness, thus LLVM's GetHostTriple.cmake guesses on the same
architecture as running the build), thus pass it manually.
This didn't use to matter, as the tests for whether --target=<target>
works used to fail, as the toolchain isn't complete at that point.
But since 7af584ed87cc6eddb6adbc451c90fb8867469e06 in llvm-project
(November 5th 2021), the libunwind cmake tests for --target do
succeed (without noticing that linking actually will fail), and thus
can end up using the incorrectly guessed compiler target.
Thus, this fixes building the runtimes with current git main
versions of llvm-project.
Specifying -lunwind isn't needed if building a version of libcxx
after 5f9be2c3e37c0428ba56876dd84af04b8d9d8915 (Feb 2021); then
libcxx is built with -nostdlib++ which keeps automatically linking
in -lunwind if -unwindlib=libunwind is used.
These don't seem to be necessary in practice at the moment.
If building on top of a stripped llvm install, while there's an
older version of llvm (providing llvm-config) installed system
wide, we currently still manage to build things correctly.
(If llvm-config from LLVM 6.0 is available, build-compiler-rt.sh
fails though, but that's unaffected by this change. In current
git versions of compiler-rt, it first and foremost looks inside
the monorepo checkout instead of looking for a potentially
unrelated llvm-config binary.)
Instead set the cmake defines that indicate that libcxx is going
to be linked dynamically and going to link in libcxxabi statically,
so that libcxxabi is built statically but with dllexport attributes.
Since libcxx includes libcxxabi with
_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS defined, the libcxxabi
declarations contain neither dllimport nor dllexport.
Earlier, we didn't use to include the libcxxabi headers with
_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS defined, but defining
_LIBCXXABI_BUILDING_LIBRARY instead. This caused libcxxabi
declarations to be marked dllexport. If any such functions would
end up emitted as part of the libcxx object files, this would
have been necessary to get them properly exported.
In practice libcxxabi functions aren't generated while included
in libcxx (they aren't templates and/or header inline functions),
_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS gets defined by the cmake
files, so we don't need to set this at all any longer.
Since before the LLVM 12.x branch, these aren't necessary any
longer.
(9c30bafd59bf1078bbe1c235c7c25bf7e278e2e9 and
8a73aa8c4c3ee82e7d650c6a957937713a4a9ab4 in llvm-project)
Since 9c30bafd59bf1078bbe1c235c7c25bf7e278e2e9 in llvm-project,
libcxxabi unconditionally defines _LIBCPP_BUILDING_LIBRARY while
building.
Since 8a73aa8c4c3ee82e7d650c6a957937713a4a9ab4 in llvm-project,
libcxx defines _LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS if
LIBCXX_ENABLE_STATIC_ABI_LIBRARY is set.
This matches how it is set by default in current master versions.
This requires building a version that includes
https://reviews.llvm.org/D89863, otherwise the new/delete operators
aren't properly weak.
This used to be the default before, but has changed in the
latest master version of libcxx.
Previously, both libcxx and libcxxabi enabled it by default, but
we used to explicitly disable it on the libcxxabi side (and rely
on the default for libcxx). Instead explicitly set the intended
configuration state for both parts.
This is necessary since 8bc62db27244803 (Jun 26, 2020) in llvm-project.
Also setting it for libcxxabi and libunwind, in case it becomes
needed there as well.
For build-mingw-w64.sh to succeed when installing to such a path,
the mingw-w64 version has to be updated to the latest git master.
build-mingw-w64-libraries.sh still fails in this case, as libtool
fails to properly quote $LD in a test for whether the linker is GNU ld.
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).
Martin Storsjö