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.
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.
This reverts commit 9e628b0f2d.
If LLVM was built with --disable-dylib, then the individual
LLVM libraries may expose a dependency on zlib. By restricting
the lldb-mi build to detect dependencies outside of $LLVM_DIR,
the build of lldb-mi fails to find zlib, making it impossible to
find all the necessary dependencies, ending up with errors like this:
CMake Error at llvm-mingw/llvm-project/llvm/build-asserts/lib/cmake/llvm/LLVMExports.cmake:55 (set_target_properties):
The link interface of target "LLVMSupport" contains:
ZLIB::ZLIB
but the target was not found. Possible reasons include:
* There is a typo in the target name.
* A find_package call is missing for an IMPORTED target.
* An ALIAS target is missing.
Revert this change for now, to allow building lldb-mi against
a non-dylib build of LLVM.
This makes the docker image contain a PGO optimized compiler,
without needing to redo all of the PGO build stages in docker.
This reverts commit 8f42112719,
and fixes building the multiplatform image in a simpler way.
Instead of doing two separate builds, with separate Dockerfiles,
just do one multiplatform build of one Dockerfile, which
docker runs serially, for each one of the included architectures,
just packaging the prebuilt toolchains in the docker image.
Using Frontend instrumentation rather than IR. This gives less
total speedup, but makes the profile much more usable for cross
other build targets.
Build the full Linux toolchain in stage1; this avoids needing to
rebuild runtimes for doing the profiling in stage2, and avoids
needing to wait for stage3 to complete before cross building
for Windows.
Do the same as when cross compiling; disallow detecting dependencies
outside of the given CMAKE_FIND_ROOT_PATH. Don't export LLVM_DIR
as we no longer need to pass it implicitly that way.
This makes the errors clearer, if LLVM isn't found where expected,
instead of misdetecting it from a different installation of LLVM
in the system.
If lldb-mi would try to find other optional dependencies, they would
no longer be found; this was already the case when cross compiling
though.
As build-llvm now can create a larger variety of build dir names,
enumerating all possible suffixes becomes problematic (especially
as they don't necessarily appear in one canonical order).
Instead, iterate over potential matches. If cross compiling, it
is easy as we can require the directory to contain the expected
suffix. If not cross compiling, we have no explicit suffix to look
for, but we can check that the directory doesn't match common
cross compilation triples.
Martin Storsjö