Normally our releases are cross-built from Linux, but we also
support building the toolchain in MSYS2. Enable the custom defaults
when building the toolchain in MSYS2 too.
Notable changes for mingw users are:
- Support demangling C++ symbols on i386 in LLVM backtraces
- Don't report fatal errors when the output pipe is closed on Windows
- Ignore file access times on Windows when comparing whether files are
equivalent
Notable changes are:
- Emit -exclude-symbols: directives for hidden symbol visibility (supported
by LLD 15 and binutils ld 2.40). This allows reducing the number of
exported symbols in e.g. libLLVM-*.dll.
- Support for CFGuard on mingw, thanks to Alvin Wong!
- LLD now picks up libraries named <name>.lib when linking with -l<name>,
even if -static was specified
- Fixed SEH unwind info on AArch64 if using the AArch64 feature
PAC (Pointer Authentication Code) - previously, unwinding would fail if
running on a system that actually does use the feature. (The consistency
of AArch64 SEH unwind info was also improved for other cases.)
- Fixed stack alignment on AArch64, for stack frames large enough to
require stack probing
- Fixed llvm-objcopy corrupting some cases of object files with empty sections
- Improvements to LLDB, where it now uses the regular symbol list of DLLs
(including non-exported symbols)
- OpenMP now can be built and works on armv7 and aarch64 (in mingw
configurations)
Notable for simplifying how to cross compile LLVM itself:
- The preexisting build machine tools can be specified with one single option
LLVM_NATIVE_TOOL_DIR instead of passing a number of variables like
LLVM_TABLEGEN, CLANG_TABLEGEN etc.
This option was mostly relevant for making it possible to share
ccache between builds in different directories, due to specific
logic in CMake's Ninja generator, which used relative paths for
sources as long as they were below the main source directory
(llvm-project/llvm). This option wasn't usable on Windows.
Since CMake 3.21.0, this option no longer worked for the intended
purpose - that version of CMake changed the Ninja generator to
always use absolute paths to sources, for consistency with other
generators and to simplify things. (See commit
c564a3e3fff52ef811291c5ba8fb07a5a1b47f97 in CMake's git history.)
It is still possible to achieve ccache sharing across build
directories anyway, by setting the ccache option CCACHE_BASEDIR,
which makes ccache rewrite absolute paths to relative ones within
that tree, and by setting the LLVM CMake option
LLVM_USE_RELATIVE_PATHS_IN_FILES=ON, which adds -ffile-prefix-map
options to the compiler, to remap source paths as they are exposed
in the generated code.
(Strictly speaking, LLVM_USE_RELATIVE_PATHS_IN_FILES is only needed
if debug info is enabled. On its own, without CCACHE_BASEDIR, that
option produces compiler output that is identical across build
directories - but the absolute paths end up in the preprocessor output
in source file/line comments, which makes ccache fail to reuse the cache.)
When rebuilding in an already built directory, cmake does use
the cache file, containing what variables were set to previously.
When changing build configuration (building with a different prefix,
or changing build configurations) this can often result in failed
cmake runs.
Wipe the cache (and the rest of the cmake temp files) by default.
This makes sure that the full cmake configuration is run each time
when running the build scripts, just like it does the first time.
(This doesn't remove the build artifacts; if nothing of significance
has changed, ninja would still reuse old built files.)
By setting the env variable NO_RECONF, this behaviour can be skipped,
rerunning cmake without wiping the cache inbetween. (For cases where
the user knows that the configuration hasn't changed since the last
build, this can speed up the cmake execution time a bit.)
Notable changes are:
- Require strict matches for defines for precompiled headers in GCC
style PCH directories. This fixes some cases of building DLLs and
static libraries at the same time with libtool, with PCH.
- Support for the new embedded -exclude-symbols: directive in LLD
- Fix LLD crashes if including object files containing export directives
via the --undefined/-u option
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.)
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
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.
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 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.
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
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.)
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.
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
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
Notable changes in this release:
- Implicitly add the .exe suffix, even when cross compiling (matching
a behaviour change in GCC since GCC 8)
- Enable the dynamicbase flag by default in LLD
- Implemented the -wrap option in LLD
- Optimized the generated unwind data for aarch64, reducing the size
of the unwind data by around 60%
- Error out of LLD if trying to create a DLL with too many exports
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.
Martin Storsjö