Extend the aarch64-w64-mingw32 prefix to provide ARM64EC libraries
alongside standard AArch64 libraries, replacing the separate
arm64ec-w64-mingw32 prefix. This aligns with how MSVC distributes
ARM64EC libraries and enables the linker to process both targets
simultaneously into a single hybrid binary.
This extensively utilizes LLVM's -marm64x option, compiling both
targets in a single compiler invocation to produce hybrid object
files (unlike MSVC tools, which require separate compilation passes).
This reverts commit 64effa9a71.
It turns out that the LLD handling of the TLS data structures
("_tls_used" and "_tls_index") needs more work, causing the
arm64ec side of arm64x binaries to not get them hooked up properly.
Extend the aarch64-w64-mingw32 prefix to provide ARM64EC libraries
alongside standard AArch64 libraries, replacing the separate
arm64ec-w64-mingw32 prefix. This aligns with how MSVC distributes
ARM64EC libraries and enables the linker to process both targets
simultaneously into a single hybrid binary.
This extensively utilizes LLVM's -marm64x option, compiling both
targets in a single compiler invocation to produce hybrid object
files (unlike MSVC tools, which require separate compilation passes).
Clang expects the aarch64 compiler-rt name on ARM64EC. While this could be adjusted
in Clang, the current approach mirrors MSVC, where the core CRT is provided as
archives containing both EC and native support. Ideally, the LLVM build system would
handle this automatically, but for now we can merge it here.
When removing them, also accept that they are missing to begin
with.
Since 655933070219f2b6f3a457c7e5af7edd4b5291b4 in llvm-project
(Apr 25th), asan only gets built for x86.
Since 0c391133c9201ef29273554a1505ef855ce17668 in llvm-project
(LLVM 17), the sanitizers can be built for aarch64, and since
5ea9dd8c7076270695a1d90b9c73718e7d95e0bf (backported to
LLVM 19.1.0 RC 4), they can be built for armv7 too.
While they can be built, address sanitizer doesn't work for the
non-x86 architecture, so omit those files from the install,
to make it clear that they aren't expected to work.
Thus, in practice, this builds the ubsan and profile runtimes for
aarch64 and armv7.
If nothing was built and installed, the installation merging command
fails with an error like this:
cp: cannot stat '/tmp/tmp.OAj9E7UBhI/install/.': No such file or directory
Therefore, skip this step if nothing really was built and installed.
add an option --host-clang which will skip building llvm,
and instead provide symlinks and wrappers for clang and
llvm tools.
Currently the clang version is detected, but it does not
affect the llvm version that will be downloaded and used.
These helpers are statically linked into each DLL/EXE that uses
them.
They are primarily used for atomic access to variables that are
larger than what the platform natively can support - i.e. primarily
for accessing atomic variables larger than 8 bytes.
The fallback implementations rely on explicit locks (spinlocks
in practice).
As the locks are statically linked into each module that uses the
atomic variable, any concurrent access to such an atomic variable
from two different DLLs/EXEs wouldn't actually end up being
properly atomic.
However cross-module atomic variables (larger than 8 bytes) is
very rare so this isn't deemed to be much of a practical issue.
In GCC based toolchains, the corresponding helpers reside in
a separate shared library, libatomic-1.dll (although it can also
be linked statically).
This allows simplification, this functionality was added long
ago to CMake.
Further motivation is to be able to re-direct the installation,
make/ninja install allow this by setting DESTDIR but this
generally doesnt work well with window paths (see [1]).
[1] - https://cmake.org/cmake/help/latest/envvar/DESTDIR.html#envvar:DESTDIR
Currently, there's no practical difference if the spelling of this
triple is inconsistent, but if we'd enable e.g. the per-target
runtime directories, the exact spelling does make a difference.
For consistency, pass CMAKE_C_COMPILER_TARGET with the exact right
spelling everywhere.
This reverts commit 056cb22fb5.
The fix for avoiding needing to set CMAKE_*_COMPILER_WORKS,
which means setting CMAKE_TRY_COMPILE_TARGET_TYPE=STATIC_LIBRARY
when intiailizing the CMake project setup, was only possible to
apply on compiler-rt/lib/builtins, not other similar projects
like libunwind/libcxxabi/libcxx - so it's expected to keep needing
to set the CMAKE_*_COMPILER_WORKS flags.
Therefore it's also possible that the code in compiler-rt/lib/builtins
could be reverted, as it does have some other minor inconveniences
(it causes some other feature detections to fail, even if they're
harmless within the builtins).
Thus keep setting CMAKE_*_COMPILER_WORKS everywhere consistently.
Since 23c665371a98c7a16765d12bf2db19b0626b7181 in llvm-project
(Nov 2, 2022), compiler-rt uses CMake's find_package() for
finding potentially installed LLVM files, instead of using
llvm-config.
If the surrounding distribution does have an unrelated install
of LLVM packages, compiler-rt's CMake files would find this, and
add include directories from it into the include paths used
when building compiler-rt.
The ORC runtimes include libc++ headers, and those error out
on these unexpected include topologies (when libc++'s cstddef
includes stddef.h and expects to get libc++'s stddef.h, but ends
up getting a different stddef.h included). (Without this,
it wouldn't have been noticed that the build ends up using a
mismatched sysroot's headers.)
This fixes building in msys2 in the clang64 environment, where
the base toolchain packages end up including LLVM packages,
including LLVMConfig.cmake.
This fixes the same issue as
3b96433cdf did, for the new form of
compiler-rt cmake files.
When rebuilding in an already built directory, cmake does use
the cache file, containing what variables were set to previously.
When changing build configuration (building with a different prefix,
or changing build configurations) this can often result in failed
cmake runs.
Wipe the cache (and the rest of the cmake temp files) by default.
This makes sure that the full cmake configuration is run each time
when running the build scripts, just like it does the first time.
(This doesn't remove the build artifacts; if nothing of significance
has changed, ninja would still reuse old built files.)
By setting the env variable NO_RECONF, this behaviour can be skipped,
rerunning cmake without wiping the cache inbetween. (For cases where
the user knows that the configuration hasn't changed since the last
build, this can speed up the cmake execution time a bit.)
We normally don't install all tools (including llvm-config), or we might
have stripped them out, but the system distro might have installed a copy
of llvm-config (for a different unrelated installation of llvm).
Some compiler-rt runtimes (such as xray and orc) use this for finding
the main llvm headers.
When building compiler-rt, we really don't want it to pick up any random
version of llvm headers found on the system, but keep using the matching
headers from the monorepo instead.
Adding the include directory of a system provided set of llvm headers
is especially fatal if that directory isn't a subdirectory containing
only llvm headers, but contains other system headers too.
In particular, on msys2, the include directory (pointed at by "llvm-config
--includedir", and also set by including LLVMConfig.cmake which is
pointed at by "llvm-config --cmakedir") is the main system include
directory. Including this can also get headers for a system install
of libc++ headers (for the clang64 msys2 distro) - and using libc++
headers with a second set of libc++ headers in the include path is
fatal (due to include_next not finding the plain C header but finding
a second libc++ header).
Just try to make sure that we don't pick up any unintended headers.
This command isn't a standard tool; different distributions have
different implementations, and e.g. Fedora doesn't ship it by
default.
Settle on using "command -v $tool >/dev/null" for tests about whether
a tool is available. (We could also use "hash $tool 2>/dev/null" as we
already had in build-all.sh, but settling on using "command -v"
everywhere, for consistency and simplicity.)
This reverts parts of commit e35ef3b7d7.
This is now handled better upstream, since
7af584ed87cc6eddb6adbc451c90fb8867469e06 in llvm-project
(November 5th 2021).
Since 8368e4d54c459fe173d76277f17c632478e91add in llvm-project (pushed
on March 11 2021), the lib/builtins CMakeLists.txt sets
CMAKE_TRY_COMPILE_TARGET_TYPE to STATIC_LIBRARY, which makes the
compiler tests pass before the toolchain is fully functional, by not
doing linking tests.
This still requires manually moving the dll files to the arch specific
runtime directory.
This requires building a version of llvm past
8e11bede3a6ac11ebcc05c82fac39899feaf9534 (March 18th 2021)
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).
On windows, we rename clang.exe to clang-$MAJOR.exe, and later
install clang.exe as a wrapper for the default architecture. But
if only building certain architectures, and the host architecture
isn't one of them, we shouldn't install any unprefixed clang.exe at
all.
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.
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.
Jacek Caban