As the preinstalled CMake on the windows-11-arm runners currently
is an x86_64 build, we need to explicitly specify
CMAKE_SYSTEM_PROCESSOR, and CMAKE_SYSTEM_NAME to make CMake
consider it a cross compilation (otherwise CMAKE_SYSTEM_PROCESSOR
gets overridden by CMAKE_HOST_SYSTEM_PROCESSOR, which gets influenced
by the x86_64 as CMake is running emulated).
We also need to set LLVM_HOST_TRIPLE, as the autodetection of
it relies on CMAKE_HOST_SYSTEM_PROCESSOR. The host triple needs
to be in normalized form with "-windows-gnu", otherwise a couple
dozens of tests fail.
We also include the AArch64 target, to make sure the built compiler
can generate code for the host.
Since 07bc54bf4554398b199f4dc849e5193b98422f23 in llvm-project
(May 5th), these tests should pass on aarch64 too.
Since 3e56f5f41843204b6e612362542b77110f8f8188 in llvm-project,
this should pass for all 4 architectures. (This doesn't pass
in the pinned release version right now.)
This avoids relying on finding these dependencies in $PATH while
running the tests. Some tests may set PATH="" while executing them,
which previously caused those tests to fail in this build setup.
The same is not an issue with MSVC builds with
-DCMAKE_MSVC_RUNTIME_LIBRARY=MultiThreadedDLL, because those
DLLs are also available in global system directories (including
DLLs such as msvcp140.dll and vcruntime140.dll).
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.
While msys2 itself may be x86_64 running emulated, it still does
indicate whether the host machine runs ARM64 (since recent
changes in https://github.com/msys2/msys2-runtime/pull/244 and
https://github.com/msys2/msys2-runtime/pull/245).
The msys2 uname command also exposes the Windows build number,
which allows determining whether armv7 and/or x86_64 binaries
can be executed.
This matches what 28851edf164a337c334755ae33fd58f03cffd5a2 in
llvm-project did.
When setting up the built libcxx files for testing, the built
files are installed into a temporary test root, and the install of
them litters the build log with mostly uninteresting output.
This was not converted in 5fe2e05419,
probably because those (automake based) makefiles work fine with
BSD make.
Use $MAKE here anyway, for consistency.
As the releases are built (without a surrounding extra container)
on GitHub Actions these days, we don't need to hold the docker
images back to an old version for the sake of compatibility;
instead, updating to a newer version provides more modern tools
for users of the docker image.
The script release.sh, which earlier was used for building releases,
uses docker for doing clean isolated builds, and thus needs to be
updated with the distro version used in the dockerfiles.
CMake 4.0 removed compatibility with CMake versions below 3.5.
Therefore, it errors out on projects with a
cmake_minimum_required() less than 3.5.
(Since CMake 3.31, it already warns that compatibility with versions
below 3.10 is deprecated.)
By passing CMAKE_POLICY_VERSION_MINIMUM=3.5, we indicate that
we are ok with configuring this project with the policies of
CMake 3.5, even if the project files themselves don't state it.
This flag is only recognized by CMake 4.0; older versions will
only warn that the manually specified variable is unused.
Relevant changes in LLVM 20.1.x compared with LLVM 19.x are:
- Don't warn when doing LTO with mixed Rust/C object files, where
the target triples differ in the vendor field
(<arch>-w64-windows-gnu vs <arch>-pc-windows-gnu)
- Fix including LLVM/MSVC style import libraries in libraries linked
with --whole-archive
- Support for files over 2 GB in the libcxx fstream methods
tellg()/seekg()
- Lots of work on improved ARM64EC and ARM64X support in LLVM and LLD
- New linker flags --dependent-load-flag and --functionpadmin, similar
to the corresponding lld-link/MS link.exe flags
- Improvements in address sanitizer, supporting many more x86
instructions
- Changes to address sanitizer, that (unintentionally) makes it fail
harder than before when used together with msvcrt.dll. Using
address sanitizer with msvcrt.dll is unsupported though.
Martin Storsjö