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.
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
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.
Passing --instrumented=IR or --instrumented=Frontend builds
instrumented tool binaries. After running them and merging the
output profile files, run build-llvm.sh with
--profile=profile.profdata.
When cross compiling with llvm-mingw, we already implicitly use
clang and lld, but we don't need to specify these options as they
are set implicitly via the llvm-mingw wrappers.
Don't use tools from $PREFIX/bin automatically; this can be
confusing and problematic. If running with $PREFIX/bin in path,
the build at this stage gets reconfigured if rebuilding after
installing clang.
For multistage builds, install into separate toolchain
directories and add the right one to $PATH before invoking
build-llvm.sh. If one really wants to use the tools from $PREFIX
for a new build into the same directory, one has to add that
directory to the path manually.
This is an option I set outside of this script in a number of
build cases where I build with ccache; move this into the script.
In practice it has little effect though; one has to set
CCACHE_BASEDIR anyway in order to be able to share a ccache
between build directories.
If enabling ccache by adding e.g. /usr/lib/ccache to the front of
PATH, without using the COMPILER_LAUNCHER variable, this won't
get enabled.
Relevant changes in LLVM 20.1.x compared with LLVM 19.x are:
- Don't warn when doing LTO with mixed Rust/C object files, where
the target triples differ in the vendor field
(<arch>-w64-windows-gnu vs <arch>-pc-windows-gnu)
- Fix including LLVM/MSVC style import libraries in libraries linked
with --whole-archive
- Support for files over 2 GB in the libcxx fstream methods
tellg()/seekg()
- Lots of work on improved ARM64EC and ARM64X support in LLVM and LLD
- New linker flags --dependent-load-flag and --functionpadmin, similar
to the corresponding lld-link/MS link.exe flags
- Improvements in address sanitizer, supporting many more x86
instructions
- Changes to address sanitizer, that (unintentionally) makes it fail
harder than before when used together with msvcrt.dll. Using
address sanitizer with msvcrt.dll is unsupported though.
This allows using the build-llvm.sh script for doing a cross build
of LLVM, while the same directory may contain a native build
which can be out of sync with the actual source.
Martin Storsjö