checkout@v5 should be the same as checkout@v4, just running on
Node 24. checkout@v6 has got a few other minor changes that
shouldn't make any difference; opt in to newer behaviours now.
This fixes importing the _ctypes module, if a shared libffi doesn't
happen to exist on the host system with the right so version.
Since Python 3.12, such a build error ends up failing the build,
while it previously passed silently even if some parts of the build
had failed.
This makes sure the openmp tests actually are executed; since
switching to the runtimes build of openmp for the tests (in
98684ab807), the tests weren't
executed, as it no longer found the tools necessary for executing
the tests - as they are expected to be specified differently
in the runtimes build mode.
This requires the commit 48a5119d8e7d7236a28c14d06ec215ef3366ef90
(backported to 22.x in 9794a7932465bdc244b327388905d66df38485e2,
part of the 22.1.1 release) in llvm-project, to be able to run
tests without actually building clang in the same build as the
test tools.
Since 6295b8e763503644961f9087382f80965b98d466 in llvm-project,
one no longer can configure the openmp project entirely standalone,
one has to do it through the runtimes directory.
However, in practice, this currently leads to no tests being
executed at all, as the runtimes build setup doesn't support
pointing to an external FileCheck executable - it currently has
to be part of a full bootstrapping build.
Since 6295b8e763503644961f9087382f80965b98d466 in llvm-project,
it's no longer possible to build openmp entirely standalone;
now one has to build it through the runtimes directory.
This version of mingw-w64 includes the function "mkdtemp", which
breaks building the previously pinned version of busybox-w32 on i686.
Update both projects in sync, so that builds with newer nightly
versions of mingw-w64 also succeed.
Some notable changes since LLVM 21.x related to mingw:
- Handle an uncommon error code in libcxx's std::filesystem,
avoiding spurious test failures if running the libcxx test suite
(noted at least occasionally on Github Actions)
- Reinstate x86 stack probe functions in compiler-rt, that we earlier
beleived weren't used - but turned out to be used by GCC in i386
mode
- Fix interpretation of a few corner case aarch64 SEH unwind opcodes
- Support for FAT LTO (compile with -ffat-lto-objects, link with
-Wl,--fat-lto-objects)
- llvm-objcopy: Support the -p option for COFF targets
- llvm-readobj: A new option --coff-pseudoreloc for dumping information
and symbols for mingw runtime pseudo relocations
- Lots of various fixes for the cygwin target
- Improve linking a custom CRT with binutils ld (by passing the custom
CRT -l option at the same place as the original default -lmsvcrt)
- Make lld use the right mingw specific DLL entry point implicitly,
improving some Rust use cases
- Fix running the libcxx tests with optimization for mingw targets,
allowing more test coverage of the code generation paths
The built-in make is a POSIX make tool, which doesn't support
GNU make features.
As we do have GNU make, insert that as "make.exe" in the busybox
directory. Don't do that in the main llvm-mingw bin directory,
which can be used with other environments (e.g. msys2), where the
native make is to be preferred.
This allows running the built busybox on older versions of
Windows that don't support the utf8 manifest. (The utf8 manifest
is supported since Windows 10 update 1903.)
When building with mingw32-make, it prefers executing commands
through "sh.exe" if it is available.
When busybox sh.exe executes "ar", it prefers executing its own
internal tool over a potential external tool found in $PATH.
(This can be avoided by setting 'export BB_OVERRIDE_APPLETS="ar"',
but as this build of busybox is expected to be used with llvm-mingw,
disable the built-in "ar" tool outright.)
According to https://github.com/mstorsjo/llvm-mingw/issues/533,
if OCaml support is detected and the LLVM OCaml bindings are built,
they are attempted to be installed in a path that require root access.
Martin Storsjö