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.
This is necessary for CMake to detect working IPO (LTO); if the
compiler is named <target>-{gcc,clang}, CMake expects to find
matching tools named <target>-llvm-{ar,ranlib} too. (The CMake
module CheckIPOSupported and function check_ipo_supported expects
to have CMAKE_LANG_COMPILER_AR and ..._RANLIB set to working tools;
the Clang-FindBinUtils.cmake module looks for tools named
llvm-ar/llvm-ranlib with the same prefix as the compiler.)
A regular GCC install doesn't provide tools like <triple>-{cc,c99,c11},
so there's probably not much need to include them.
Some distributions of tools may provide tools with the names "cc",
"c99" and "c11" though, as custom frontends or symlinks to the
regular compiler. Therefore, keep the unprefixed tools with these
names.
This includes building universal binaries (for arm64 and x86_64)
and targeting an older minimum deployment target.
(Before 1919720fdd348ca568b235bf3f1357c198eccd15 in llvm-project,
Jan 2022, building lldb's debugserver failed, if building for macOS
for multiple architectures, or for an architecture other than the
current host.)
Since LLVM 13, llvm-dlltool can imply the target architecture from
a triple prefix on the tool name, so there's no more need for a
wrapper.
The *-dlltool tools are now symlinks to the main llvm-dlltool
executable. In the Windows distribution, the *-dlltool.exe used to be
copies of dlltool-wrapper.exe (which is small; 15 KB). Now they
will instead be copies of llvm-dlltool.exe. Luckily, thanks to
building with -DLLVM_LINK_LLVM_DYLIB=ON by default, llvm-dlltool.exe
is only a mere 65 KB, while it used to be much larger, e.g. around
11 MB in older releases.
Printing '<triple>' causes the shell to try to read a file named
triple. One could either quote it, or just remove the angle brackets;
removing the brackets for simplicity.
On windows, we rename clang.exe to clang-$MAJOR.exe, and later
install clang.exe as a wrapper for the default architecture. But
if only building certain architectures, and the host architecture
isn't one of them, we shouldn't install any unprefixed clang.exe at
all.
For build-mingw-w64.sh to succeed when installing to such a path,
the mingw-w64 version has to be updated to the latest git master.
build-mingw-w64-libraries.sh still fails in this case, as libtool
fails to properly quote $LD in a test for whether the linker is GNU ld.
This saves a lot of diskspace, when symlinks are turned into full
copies of the tools on windows, as the symlinks only point to a small
wrapper instead of to the full tool.
This allows non-msys build systems to use the triplet prefixed
compiler frontends on windows.
Keep the old shell script version as well, for easier hackability
on unix platforms.
For x86 architectures, binutils objcopy and strip can be used as
such.
For armv7 and aarch64, binutils doesn't recognize the architectures
and refuse to touch the files. For most/everything that objcopy/strip
do, the actual architecture doesn't really matter though. Therefore,
provide a wrapper script and a minimal tool for editing PE executables,
that change the architecture from armv7 and aarch64 to i686 and x86_64
respectively before invoking binutils, and change it back afterwards.
In case the binutils tools are missing, just return a successful result
without doing anything for stripping operations (previously, we had the
<triplet>-strip tool symlinked to /bin/true, so this isn't any worse than
before) and fail for other objcopy operations.
If installing on top of a prebuilt win32 release of llvm instead of
building from source, the nm and strings executables are missing,
and MSYS2 errors out when creating a symlink to a file that doesn't
exist (since it does a copy instead of making an actual symlink).
This makes the output architecture independent, allowing
the x86_64 GNU binutils binary to be used for other
architectures as well, including arm/arm64 which aren't supported
by binutils.
Provide wrappers named <triplet>-gcc and <triplet>-g++ as well,
to ease cross compilation with e.g. autotools, to allow just
specifying --host=<triplet>.
Provide wrappers for objdump and ld that provide specific output
that autotools look for.
Provide <triplet>-strip as a symlink to /bin/true, since there is
no strip tool available yet (and llvm-objcopy doesn't support
COFF yet).
Norbert Lange