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.
The main changes for mingw targets since 18.x is primarily
minor bug fixes. llvm-dlltool has also been improved to handle
cases of renamed imports, where the target of the rename doesn't
exist as a normal import.
This adds the following:
- LLD now uses the SOURCE_DATE_EPOCH env variable for setting the
COFF header timestamp
- LLD now also supports --lto-emit-asm and -plugin-opt=emit-llvm
in the mingw linker interface
Since cpython-mingw v3.11 (see cpython-mingw commit
8aeb46d09c068a1228e83b29101c17bf1ff0612a), the versionless, stable
ABI libpython3.dll gets installed, along with libpython3.dll.a.
Ideally we would use this, which gets us better flexibility, but
in practice, LLDB fails to link against this, as it doesn't expose
enough of the symbols we use and need.
Previously, we ended up with PYTHON_LIB containing two path names,
which caused CMake to print warnings about ignoring extra paths
on the command line.
This fixes issue #396.
Martin Storsjö