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.
Martin Storsjö