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.
Relevant changes/fixes since the last version:
- Added the new Clang option -fno-auto-import, affecting both code
generation (avoiding generating .refptr stubs) and linking
(passing --disable-auto-import, to avoid subtle runtime errors,
which could happen if code built without .refptr stubs would
autoimport symbols anyway)
- Fix issues with running the toolchain, or building sources on,
network mounts. Previously, there were issues with VirtualBox
shared folders or Remote Desktop shared folders.
- Pass LTO options from the compiler driver to the linker
- Support more LTO options in the linker
- LLD now implements the --icf=safe option properly
- Support using the -S/-s flags in LLD, to strip out DWARF debug
info and symbol table, while producing a PDB file
- Fix LTO issues around __imp_ symbols, making it support building
the base mingw-w64-crt files with LTO
- LLD now doesn't try to detect/add MSVC library directories when
linking in MinGW mode
- Fix building compiler-rt sanitizers, when libcxx is available only
in static form
- Fix building a standalone libclang_rt.atomic_dynamic for MinGW
targets
- Support for the MENUEX resource type in llvm-windres
- llvm-windres now supports referencing filenames in .rc files,
constructed from multiple concatenated string literals
- Various fixes for the llvm-windres option --preprocessor, including
the breaking change to match the new GNU windres behaviour from
binutils 2.36
- Don't look for a GCC in path when Clang is installed next to
a suitable sysroot (mostly relevant for MSYS2)
- Avoid exposing unprefixed mmap symbols in the profiling runtime,
which could lead to misdetections in user code
- Support for reading Windows thread names in LLDB
This version fixes the following issues for mingw/windows targets:
- Fix linking the lli tool if built with asan enabled
- Fix compiling for the aarch64 target if specifying -mtune=cortex-a53
- Fix initialization order among constructors within one translation unit
This contains a few bugfixes for mingw use cases:
- LLD in 17.0.1 and the earlier 17.x release candidates looked up
libraries (including libraries named as a relative path) preferring
to search in toolchain relative paths over first testing from the
current directory. In some cases, this could cause cryptic build
failures; see https://github.com/llvm/llvm-project/issues/67779.
- Options that only are relevant for linking, like -mwindows, used
to be accepted (but produce a warning) if used in a compilation-only
job. In the earlier 17.x releases/RCs, such warnings caused an
error instead; see https://github.com/llvm/llvm-project/issues/64464
and https://github.com/mstorsjo/llvm-mingw/issues/371.
This only provides the main binary llvm-cxxfilt; it doesn't
provide the binutils-style frontends named [<triple>-]c++filt.
If we were to provide such frontends, we'd need to make them
default to --strip-underscore for i686 triple prefixes, and
for the prefixless case when the default architecture is i686.
This allows simplification, this functionality was added long
ago to CMake.
Further motivation is to be able to re-direct the installation,
make/ninja install allow this by setting DESTDIR but this
generally doesnt work well with window paths (see [1]).
[1] - https://cmake.org/cmake/help/latest/envvar/DESTDIR.html#envvar:DESTDIR
Martin Storsjö