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 fixes linking against a DLL of libc++ while using the common headers
(generated from the static version of the library, but which work for
both shared and static versions) when calling e.g. std::filesystem::u8path.
This allows easier testing of continuing from manually set
breakpoints.
Also fix compilation for non-windows platforms where __debugbreak()
isn't defined.
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.
For x86_64 and aarch64, this requires https://reviews.llvm.org/D89231.
The C++ destructors aren't executed while doing the longjmp (contrary
to how it works MSVC's C++ exceptions), but it no longer crashes.
Notable changes in this release:
- Implicitly add the .exe suffix, even when cross compiling (matching
a behaviour change in GCC since GCC 8)
- Enable the dynamicbase flag by default in LLD
- Implemented the -wrap option in LLD
- Optimized the generated unwind data for aarch64, reducing the size
of the unwind data by around 60%
- Error out of LLD if trying to create a DLL with too many exports
This is needed since 8bd2722f65cfd7883ed9769f7bad3ff50e4c6905
(and 8e11bede3a6ac11ebcc05c82fac39899feaf9534) in llvm-project
(past the 12.x release branch), which will allow us to get rid of the
whole arch renaming part (once we can assume we're building a version
newer than that).
The dockerfiles install both tools, and the scripts that use them
(build-make.sh and build-libssp.sh) can make do with either curl
or wget, but e.g. macOS ships with curl but not wget.
Printing '<triple>' causes the shell to try to read a file named
triple. One could either quote it, or just remove the angle brackets;
removing the brackets for simplicity.
Martin Storsjö