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.
The total number of exported symbols in this build configuration has
now reached the limit for the number of exported symbols in a DLL,
with the latest version of llvm-project from git.
This isn't an issue when building with Clang, as it marks many
symbols as excluded from auto-export.
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
This raises the versions of bundled software, providing e.g.
autoconf 2.71, which is needed for Python 3.12.
As the releases are built (without a surrounding extra container)
on GitHub Actions these days, we don't need to hold the docker
images back to an old version for the sake of compatibility;
instead, updating to a newer version provides more modern tools
for users of the docker image.
Previously, when echoing the definition of BUILD_DATE to
$GITHUB_OUTPUT, that doesn't make it available as an environment
variable. (And if it would be echoed to $GITHUB_ENV, it still
wouldn't take effect until the next step within the same job either.)
Therefore, this previously set BUILD_DATE to $(date -d "" +%s),
which seems to produce a timestamp corresponding to the start of
the current day.
This sets SOURCE_DATE_EPOCH to the commit timestamp, toolchains
should pick up timestamps from this variable.
The same sources ideally would produce the same binary, see
https://reproducible-builds.org.
Set the timestamps within the tar archives to the start of the
CI pipeline.
Sort the archive contents.
The generated tar archives contain the uid/gid of the builder,
if unpacked as root on another system those will denote nothing
or an unexpected user/group.
The expectation would be uid/gid = 0.
Use a simple enough tar format as well.
The Mac version of tar (bsdtar?) does not support those flags,
for CI the separate gnu-tar is installed.
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.
These were missed in ad30b74173.
The mismatch between upload-artifact and download-artifact in
ad30b74173 makes the later steps
fail to download the artifacts from previous steps.
Since 7dcd8ef135147de1576c2863b963ec929a15e8cb in llvm-project
(Dec 15th), LLD can strip out the bundled DWARF debug info directly
when linking, while creating a PDB file, simplifying this test case.
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
These helpers are statically linked into each DLL/EXE that uses
them.
They are primarily used for atomic access to variables that are
larger than what the platform natively can support - i.e. primarily
for accessing atomic variables larger than 8 bytes.
The fallback implementations rely on explicit locks (spinlocks
in practice).
As the locks are statically linked into each module that uses the
atomic variable, any concurrent access to such an atomic variable
from two different DLLs/EXEs wouldn't actually end up being
properly atomic.
However cross-module atomic variables (larger than 8 bytes) is
very rare so this isn't deemed to be much of a practical issue.
In GCC based toolchains, the corresponding helpers reside in
a separate shared library, libatomic-1.dll (although it can also
be linked statically).
Don't assume that any host argument indicates cross compiling for
Windows.
Update build-all to pass --host arguments to strip-llvm as well,
for consistency.
This makes the built toolchain usable outside of MSYS2 too.
For running tests, this has another very subtle effect.
If the toolchain is built in the MSYS2 clang64 environment, the
compiler binary depends on libc++.dll. This DLL is found in $PATH,
in /clang64/bin.
When building/running tests, the current working directory will be
e.g. llvm-mingw/test/x86_64. At some point while building/running
tests, the test makefile will copy the llvm-mingw toolchain's
runtime DLLs into this directory in order to be able to execute those
newly built binaries. This also includes another, different libc++.dll.
When a libc++.dll exists in the current directory, this is preferred
over the one found further back in $PATH in /clang64/bin. As this
file is copied in parallel with other build jobs that might be
doing compilation, those compilation processes may end up loading
this other DLL. If fully copied it probably shouldn't be an issue,
but if not fully copied yet, who knows what might happen.
By making sure that there is a libc++.dll in the same directory as
the toolchain executables (rather than expecting it to be found
further back in $PATH), we ensure that this DLL is loaded and used
instead of the one in the current directory.
This should fix stray errors when running tests in the clang64
environment.
This version fixes a race condition in the build, which in most
cases was benign but in rare cases could successfully build a Python
that would crash at runtime.
This skips test that use a lot of memory. In particular, there's
one test that would use up to 6.8 GB of memory, while the GitHub
Actions runners only have 8 GB of memory available.
This parameter was added in 122064a6303eb9c06e0af231f5a4ce145d9a2e67
in the llvm-project main branch, and backported to 17.x in
aa03fba83b17bbfcd9ed869efed2818b503875d6.
This allows seeing the names of tests as they are executed, making
the intermediate log output on github actions more useful. It
also makes it easier to correlate test issues between tests as
they are executed (e.g. if one test causes another one to run out
of memory).
Also run with --time-tests, allowing identifying slow tests.
This was already applied in the separate libcxx test job added in
7483eae1821766a0f84dbd96f5619058f7065008; this backports the change
into the test job in the main build file.
Norbert Lange