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.
Since 6127724786d581d2653df7420d1f28709288a107 in llvm-project
(Nov 4 2024), this variable no longer is referenced, and it
probably hasn't been needed for much longer than that.
It's enough to check for the _UCRT define these days, as long
as we are including a header that pulls in the base mingw headers.
Since 8b2ece59fccf0a65257b1ba2fe8d67d7e8a2e8c1 in mingw-w64 (May 6th
2019), the mingw-w64 headers define _UCRT. Since
94a28397eec79e54ce5a8354512f43da88f815d2 (committed on the same date),
the mingw-w64 headers use 0xE00 instead of 0x1400 for UCRT.
This reverts commit 490dfffb32.
This is no longer necessary, as we now can build runtimes using
the latest LLVM 19 versions, that support building sanitizers
for all architectures.
Martin Storsjö