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