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.
CMAKE_ASM_COMPILER is set implicitly from CMAKE_C_COMPILER,
but the target flags aren't implied in the same way.
This fixes cross compiling LLVM with clang for an x86_64 target.
This wasn't an issue when cross compiling LLVM with clang for an
aarch64 target, because the BLAKE3 aarch64 SIMD is in the form
of a C file (with intrinsics), not a standalone .S file.
In this case, we want to incrementally build the remaining tools,
not do a full build. In case someone runs build-all.sh with CLEAN
set, the --macos-native-tools invocation of build-llvm.sh shouldn't
wipe the build directory.
Martin Storsjö