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.
This version fixes catching pointer data types by reference in C++.
This version also fixes throwing C++ exceptions on aarch64 with
a debugger attached to the process.
Finally, this version fixes delayimport calling of C++ methods that
return structs on aarch64.
These builds fail regularly, under mysterious circumstances.
("The hosted runner lost communication with the server. Anything
in your workflow that terminates the runner process, starves it
for CPU/Memory, or blocks its network access can cause this error.")
This usually seems to happen around the build-libcxx.sh step.
This allows overriding which linker to use.
Currently, building LLVM on Ubuntu 25.10 with these scripts fails,
if LLD is available. This, because the GCC on that distribution
produces object files that LLD (and gold) rejects during linking - see
https://github.com/llvm/llvm-project/issues/156667 for details.
By building with --use-linker=bfd, linking does succeed in that
configuration.
Also pass the same option through from build-all.sh.
In this case it's usually an option that wasn't recognized
(although the misrecognized option may have been an earlier
option and the current one may be the intended prefix).
These variable expansions/modifications work the same if the
option "--pgo" is specified - so either we can simplify the
stripping of the "--pgo=" prefix, or we can just skip the check,
similar to the case above with --instrumented.
For some unknown reason, macos-15 runners (which macos-latest
resolves to currently) seem to be consistently 25-40% slower than
macos-14 runners; the "macos" job (doing an universal binary build
for 2 architectures, with LTO) often take over 5 hours, and have
reached the 6 hour timeout once.
Switch this back to macos-14 to speed it up and reduce the risk of
hitting the timeout.
In the future, if/when the macos-14 runners are phased out, and if
the performance reduction in macos-15 runners remains, we'd need to
switch to building each architecture in a separate job, and merge
them together separately if we still want to provide universal
binaries.
If ARCHS itself was set by the caller, it would already have been
implicitly passed to the makefile - but if the caller set
TOOLCHAIN_ARCHS instead, that wasn't acted upon by the makefile.
As the shell script already has the logic for initializing this
(in the same fashion as all other shell scripts), just use that
and pass the value on to the makefile.
This matches what is done in build-all.sh for the PGO step; this
removes rather large (~50 MB) libraries that mostly are needed
for compiling for the host unix platforms. (On Linux it's needed
if building with profiling, on macOS it's needed for the builtin
functions for platform version availability too.)
This matches what is done for the regular builds; we run (build-only)
tests already with the first cross compiler toolchains, not needing
to wait for the cross compiled toolchains to run on Windows.
This is required for properly formatting long doubles on x86
with UCRT (which doesn't use the mingw builtin printfs by default).
This fixes running the LLVM testsuite on x86 after commit
9bf7d04c4386daf1ef0acf95782a59855c98474a in llvm-project.
Relevant changes include:
- Lots of work for supporting ARM64EC and ARM64X
- LLD now produces more compact string tables in executables (only
relevant when including debug symbols)
- llvm-rc now supports multiplication/division expressions, like GNU
windres
- Improved support for armv7 and aarch64 in libunwind (for Itanium
ABI "forced unwinding", which I'm not aware of being used in
practice anywhere)
- Made the libunwind, libcxxabi, libcxx and compiler-rt tests pass on
armv7 and aarch64 mingw
- Made the llvm/clang tests pass on aarch64 mingw
The ARM github actions runners now run on Windows 11 10.0.26100,
which no longer support executing armv7 binaries. (Previously they
were running Windows 11 10.0.22631.)
If using Clang from /usr/bin, this makes it clear to CMake to use
$HOST-strip, as it otherwise may pick plain /usr/bin/strip, which
may not be able to strip the cross built executables.
Martin Storsjö