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.
This sets the variable CLEAN=1 after building the tools, which makes
all the builds of the runtime libraries remove old build dirs
before building.
This is similar to, but has a slight different purpose than
the existing --wipe-runtimes, which removes the installed runtime
files. Both are useful when testing various build configurations
and investigating issues, for different testing scenarios.
add an option --host-clang which will skip building llvm,
and instead provide symlinks and wrappers for clang and
llvm tools.
Currently the clang version is detected, but it does not
affect the llvm version that will be downloaded and used.
Don't assume that any host argument indicates cross compiling for
Windows.
Update build-all to pass --host arguments to strip-llvm as well,
for consistency.
This was added in 050b4ef701, but this
option was never supported to be passed on to build-llvm.sh from
here.
Additionally, this option was removed entirely from build-llvm.sh
in bd190c04c3.
Curl (or wget) isn't required for fetching libssp any longer,
so don't require it while running build-all.sh.
(It's still required by build-cross-tools.sh, for build-make.sh
though.)
As mingw-w64 now provides these routines, we no longer need to build
the original library from GCC.
As building with -fstack-protector-strong still links with -lssp
(and -lssp_nonshared), we still need to provide libraries with these
names, but they can be empty dummy libraries.
This command isn't a standard tool; different distributions have
different implementations, and e.g. Fedora doesn't ship it by
default.
Settle on using "command -v $tool >/dev/null" for tests about whether
a tool is available. (We could also use "hash $tool 2>/dev/null" as we
already had in build-all.sh, but settling on using "command -v"
everywhere, for consistency and simplicity.)
When --unwindlib=libunwind is implicit, we need to build libunwind
to have a complete working C compiler too. Currently this is worked
around by initially creating a dummy, empty libunwind.a, but with
the current version of libcxx/libunwind, we can get rid of that
workaround if we build it as soon as possible.
Building this tool requires having a full LLVM build available;
either by installing without LLVM_INSTALL_TOOLCHAIN_ONLY (and not
stripping the llvm installation yet) or by pointing it at the
LLVM build directory instead. The latter works better for our
normal build flows.
The dockerfiles install both tools, and the scripts that use them
(build-make.sh and build-libssp.sh) can make do with either curl
or wget, but e.g. macOS ships with curl but not wget.
This simplifies build-mingw-w64.sh. When building on native
windows (where we also provide unprefixed tools, we can't have
the yet incomplete compiler toolchain in $PATH when building
the mingw-w64 tools. (Logically, build-mingw-w64-tools belong
with build-llvm and install-wrappers; using the original system
compiler to build tools that are supposed to run on the current
machine, as opposed to the cross target, like when building the
runtimes.)
gcc/libssp's configure script runs checks for flags that clang doesn't
implement. We actually just need to set a few HAVE defines and compile
the .c sources, so just check out this subdirectory using svn and build
it using a custom makefile.
Norbert Lange