46efff459a regressed this aspect,
where libLLVM-<version>.{so,dylib,dll} was meant to be kept, but
also ended up keeping libLLVM<name>.a. (This only matters if trying
to strip a build done with --full-llvm.)
Since LLVM 15, libc++experimental should work fine with libc++
configured for shared linking, and libc++experimental is enabled
unconditionally, and LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY is
ignored now.
This avoids needing to run the cmake configure for the nested
native build.
This tool (part of clang-tools-extra) is new in LLVM 15.0.0
(and the cmake setting for specifying the binary was backported
after the 15.x branch was made, but before rc1 was tagged).
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.)
Since 93010544a813dfbfa64dd7cee68785f572f974d1 in llvm-project
(Jun 22nd), this no longer is needed for being able to build
native tools with a nested cmake in a cross build. (If building in
the same tree as a previous native build, build-llvm tries to pick
up the tblgen tools from there, so in such cases, this doesn't
make any difference and the nested native cmake invocation never
was executed.)
Since bedf657d0f4c54ffe9ef4303382657a74296b544 in llvm-project
(May 18th), a static libc++ built at the same time as a shared one
no longer contain dllexport directives, making that library actually
usable.
Since dfa88927ae1411ccc3b248b7e624f2acf623d947 (Jun 6th), the
libc++ headers no longer have dllimport attributes, making the headers
installed from a build containing a shared library usable both
for the shared and static library, without the user having to set
any specific defines.
These two changes allow removing the manual build workarounds of
building the libraries in separate CMake invocations in a specific
order.
Notable changes are:
- Fix stripping Rust executables with .rmeta sections
- Implemented support for SEH unwind info on the armv7 target
- Fix compiling files specified with an absolute \\?\C:\... style path
- Implemented support for the --disable-reloc-section option in lld
- Lots of improvements in LLDB on Windows (thanks to Alvin Wong!)
- Support for GNU debuglink
- Fix loading DLLs from a ramdisk
- Fix starting executables without including the '.exe' suffix
- Fixed crashes on getting nested exceptions
- Use the right C++ ABI for mingw environments
Other changes that simplify how to build the toolchain:
- Improvements to how libcxx/libcxxabi/libunwind are built for Windows
(and in particular mingw), allowing building both shared and static
libraries in the same cmake build
- Avoids needing to set an empty CROSS_TOOLCHAIN_FLAGS_NATIVE when
cross compiling LLVM
Notable changes are:
- Fix building for armv7 with SEH enabled
- Implement _set_com_error_handler and _com_raise_error in comdef.h
- Add import libraries for older msvcrXX.dll versions
- Redirect access() to __mingw_access() on UCRT
- Assorted updates to Windows APIs
Zstd is available and gets autodetected, but it's only available in
native form, not in arm64 form.
Also, for the existing workaround, instead of entirely disabling lldb,
one could pass -DLLDB_ENABLE_PYTHON=OFF instead.
Test building the toolchain on all supported platforms for building
it (linux, macOS, msys2). Produce cross-built standalone toolchains
that run on Windows for all 4 supported architectures.
Run scheduled builds (daily), built with the latest git versions of
most components. For scheduled builds, the linux toolchain is built
with assertions enabled, as latest git version of llvm occasionally
can have regressions, and many such are caught by having assertions
enabled and building enough code that exercise many code generation
cases.
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.
Check for the prescence of the llvm-tblgen binary in addition to just
checking whether the llvm/build or llvm/build-asserts directories
exist.
In cases where having multiple build directories around, where some
are older than others, it's now possible to clarify which one to use
for tools by just removing the llvm-tblgen binary from the other ones.
Also check for the prescenece of each individual tool before setting
it; this fixes builds where the native build might not have all
components enable as as enabled in the cross build.
The install(1) tool on macOS doesn't support the -D option for
creating directories at the same time while installing files.
Therefore, run a separate step for creating directories. Doing that
with "mkdir -p", even if install(1) also could do that with the -d
option (likewise with a separate command).
Also stop specifying the destination file name, when it's equal to
the source files, now that we know that the destination directory
already exists.
Compared with RC2, the only notable change for mingw targets is
that sections named .debug_* are sorted to the very end of the
image, after any other discardable sections, avoiding leaving gaps
if stripping such executables. (This can affect rust binaries with
a .rmeta section.)
This fixes the v*scanf functions when using msvcrt.dll, if using more
than 30 format conversions, fixes error handling in the btowc
function in libmingwex, and adds a missing (void) in a function
prototype in winpthreads, adds the fwpuclnt import library for aarch64,
plus other assorted header/interface updates.
This installs a bunch of new tools in the bin dir, namely the following:
clang-apply-replacements
clang-change-namespace
clang-doc
clang-include-fixer
clang-move
clang-query
clang-reorder-fields
clang-tidy
clangd
find-all-symbols
modularize
pp-trace
run-clang-tidy
These are stripped out by strip-llvm, but clangd and clang-tidy
are kept.
While lldb can be used as a cross debugger, it's probably mostly
used when run on the same target as the code is executed on.
Since it's a mostly optional component in the toolchain, allow
passing --disable-lldb to build-llvm.sh to skip it.
Allow setting up the projects with symlinks by passing --symlink-projects
to the build script.
The setup with symlinks is mostly useful in development setups, where
one wants to share ccache across multiple checkouts.
If the SYNC variable is set when running build-all.sh, all the
individual scripts will try to check out the intended version
before building. All scripts that build projects from llvm-project
(build-libcxx.sh, build-compiler-rt.sh, build-openmp.sh) call
build-llvm.sh with CHECKOUT_ONLY=1 to make sure the right version
is checked out (as one can call the scripts individually too).
If the llvm-project directory was a full (non-shallow) checkout,
the repeated fetch was quick as git knew that it had the fetched
reference already. But in a shallow clone, a new shallow fetch
would refetch the whole object tree for the targeted reference.
Using "git cat-file -e" we can check whether a specific object
exists in the local checkout, avoiding needlessly refetching
everything.
However, when fetching a tag using shallow fetch (git fetch
--depth 1 origin "$LLVM_VERSION"), it would only fetch the
commit object for that tag, not the tag itself. By specifying
'tag "$LLVM_VERSION"' in this case, we get the tag object itself,
so that we later can check whether "$LLVM_VERSION" exists in the
local checkout. But this requires guessing whether a specific
"$LLVM_VERSION" is a tag or a commit.
This reverts commit bd9e16f732.
It turns out this actually isn't needed; since switching to
building via the llvm-project/runtimes directory (in
7b1d05f545), the cmake build
pulls in HandleLLVMOptions.cmake, which checks for and adds
-ffunction-sections and -fdata-sections if supported. Therefore,
we don't need to specify it manually at all.
Notable changes include:
- Default to DWARF 4 instead of 5 for the mingw target
- Fix the section name encoding in llvm-objcopy/llvm-strip, if the output
binary has more than 10^6 bytes of string table
Clang's general default dwarf version was raised from 4 to 5 in
d3b26dea16108c427b19b5480c9edc76edf8f5b4 in llvm-project (Jan 23
2022) before the 14.0.0 branch, but dwarf 5 on Windows seems to not
work with either LLDB or GDB.
Thus force the default back to 4 here as a temporary workaround, and try
to set the default back to 4 for mingw targets in Clang for later
releases (https://reviews.llvm.org/D119326).
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.)
This makes warnings for other unused arguments visible to the user.
This requires a version of llvm-project past
50ec1306d060e46e0d53c9f5d8a052e1b0d10d3b (Jan 2022) which added these
new options.
This reverts parts of commit e35ef3b7d7.
This is now handled better upstream, since
7af584ed87cc6eddb6adbc451c90fb8867469e06 in llvm-project
(November 5th 2021).
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.
Since df0ba47c36f6bd0865e3286853b76d37e037c2d7 in llvm-project
(November 5th 2021), clang built with mingw defaults to producing
paths with forward slashes - thus, this hack no longer is needed.
Since a8d15a926689c126c4d316788786e0160cfc1d5d in llvm-project
(October 5th), libcxx stopped autodetecting pthreads on mingw,
making pthreads opt-in instead of opt-out.
Notable changes include:
- LLVM can be configured to prefer forward slashes on Windows, avoiding
the need to manually filter the Clang output in a wrapper for some
commands.
- New Clang options for silencing warnings about unused arguments,
avoiding the need to turn off the warning altogether. This makes
llvm-mingw produce warnings about unused arguments among the user
provided arguments, which never were seen before.
- Improvements to building libunwind/libcxxabi/libcxx, allowing
simplifying the build a lot.
- Fixed generated calls to support routines for converting 128 bit integers
from/to floats on x86_64.
- Fixed the -m32 flag, to let it figure out the right i386/arm
architecture variant (where it previously looked for a sysroot named
e.g. i386-*, which wasn't found).
- Fixed code generation for AArch64 in large object files (over 1 MB of
code), where relocations against temporary symbols (jump tables,
constant pools etc) were broken.
- Fixed continuing from breakpoints and singlestepping in LLDB on
ARM/AArch64
- Fixed unwind info for overridden weak symbols (e.g. if overriding
operator new with a statically linked libc++, and unwinding an exception
through the operator).
- Set proper COFF symbol types for function aliases (e.g. for some C++
constructors), making GNU ld export all of the correctly as the right
type, when linking a DLL.
- Improved code generation for ARM, by assuming less strict alignment
requirements for some instructions.
This is the build host python, run during the build/install,
not to be run on the target device. LLVM's build system itself
detects the python to use for that and overwrites the
Python3_EXECUTABLE variable anyway, so it's value isn't currently
used.
Even if we don't patch cpython-mingw any longer, we still run
autoreconf on it (and libffi), which can cause changes to
committed files. If trying to check out a different version of
the source, this would fail unless the local changes have been
discarded.
LLVM's default host detection doesn't always work (cmake doesn't
detect and provide the target architecture, but it provides the
bitness, thus LLVM's GetHostTriple.cmake guesses on the same
architecture as running the build), thus pass it manually.
This didn't use to matter, as the tests for whether --target=<target>
works used to fail, as the toolchain isn't complete at that point.
But since 7af584ed87cc6eddb6adbc451c90fb8867469e06 in llvm-project
(November 5th 2021), the libunwind cmake tests for --target do
succeed (without noticing that linking actually will fail), and thus
can end up using the incorrectly guessed compiler target.
Thus, this fixes building the runtimes with current git main
versions of llvm-project.
Specifying -lunwind isn't needed if building a version of libcxx
after 5f9be2c3e37c0428ba56876dd84af04b8d9d8915 (Feb 2021); then
libcxx is built with -nostdlib++ which keeps automatically linking
in -lunwind if -unwindlib=libunwind is used.
In addition to the changes in 13.0.0 RC1 (listed in
9188cce153), the following changes
relevant to llvm-mingw were made:
- Allow specifying language to llvm-rc with an 0x prefix
- Let the last specified option of -mconsole/-mwindows take effect
- Support both "--opt value" and "--opt=value" for more options in lld
- Add support for the --disable-dynamicbase option spelling in lld,
in addition to the old existing --no-dynamicbase
- Fix linking with when enabling profiling
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.
The import libraries for libLLVM/libclang-cpp are rather large
(21 and 15 MB each), while it hasn't been too much of an issue
with liblldb.dll.a (which was 600 KB).
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.
Since 8368e4d54c459fe173d76277f17c632478e91add in llvm-project (pushed
on March 11 2021), the lib/builtins CMakeLists.txt sets
CMAKE_TRY_COMPILE_TARGET_TYPE to STATIC_LIBRARY, which makes the
compiler tests pass before the toolchain is fully functional, by not
doing linking tests.
This still requires manually moving the dll files to the arch specific
runtime directory.
This requires building a version of llvm past
8e11bede3a6ac11ebcc05c82fac39899feaf9534 (March 18th 2021)
Notable changes since 12.0.0 for llvm-mingw are:
llvm:
- Produce proper cross-section relative relocations on ARM and AArch64
- Fixed the calling convention for AArch64 for variadic functions involving
floats in the fixed arguments
- Added a windres compatible frontend in llvm-rc, avoiding the need for
external wrappers
- Build LLVM with -ffunction-sections and --gc-sections, shrinking
a full build of llvm-mingw without LLVM_BUILD_LLVM_DYLIB by 22%
(but llvm-mingw uses LLVM_BUILD_LLVM_DYLIB these days, which shrinks
the build even more)
- Avoid optimizing/changing function calls into stpcpy due to optimizations
- llvm-ml has improved to the point where it can build the OpenMP assembly
file without needing to use another assembler tool
lld:
- Support linking directly against DLLs without using import libraries
- Improved reliability when running on Windows, avoiding some hangs
when terminating
- Fixed linking with --export-all-symbols in combination with
-ffunction-sections
- Fixed --export-all-symbols when linking EXEs
- Fixed autoexport from LTO objects with comdat symbols
- Print warnings with a "ld.lld" prefix instead of "lld-link"
- Avoid thread exhaustion on 32 bit Windows
- Accepting more forms of options, like -static and --stack=
clang:
- Fixed reading long doubles with va_arg on x86_64
- Fixed calling std::once in a dynamically linked libstdc++
runtimes:
- Complete support for std::filesystem in libc++ (which was previously
backported to 12.0.0 in llvm-mingw too, but the previous release had
a bug in using e.g. the u8path() method when linking against the DLL
version of libc++)
- Implemented semaphores in libc++
- Provide the __gcc_personality_seh0 symbol, fixing building C code with
-fexceptions and __attribute__((cleanup))
- Simplified building/installing compiler-rt and libunwind
- Silenced lots of build warnings in OpenMP
Martin Storsjö