This version fixes some cases of duplicate time.h related symbols,
in some build configurations (an issue only present in the
previous snapshot). This version also uses the right format attributes
for printf/scanf functions for Clang, enabling format string warnings
when using e.g. the mingw ansi stdio routines.
When setting up wrappers for Windows, rename clang-scan-deps.exe to
clang-scan-deps-real.exe, make clang-scan-deps.exe a wrapper, and
configure the wrapper to target executing clang-scan-deps-real.exe.
This makes sure that we always pass in crucial options like
-stdlib=libc++.
By default, our Clang executables are built with that option
hardcoded, configured with CLANG_DEFAULT_CXX_STDLIB=libc++
when built for Windows. However, we generally don't rely on this;
we assume the tools could be plain default executables, so we
try to provide wrappers on all common access paths.
This picks the architecture by looking for a triple prefix in the
nested command, and passes it as an explicit flag, to let
clang-scan-deps find it.
We also pass -stdlib=libc++, to let it find the libc++ headers
as expected.
By default these files would be installed into
${CMAKE_INSTALL_PREFIX}/share/libc++/v1, where
${CMAKE_INSTALL_PREFIX} is equal to ${PREFIX}/${arch}-w64-mingw32.
However, to avoid duplicating these files for each architecture,
install them into ${PREFIX}/share/libc++/v1 instead.
While the files aren't very large (currently weighing in at around
612 KB), they're architecture independent files (and they're
more than a few; they're currently 135 files), so we should
share them if possible.
Currently, the "macos-latest" runners aren't really the latest
version - on the contrary, they're running the oldest HW/OS.
Currently, there are macos-12, macos-13 and macos-14, and macos-latest
are the macos-12 ones.
The macos-14 ones run on Apple Silicon.
Previously, the macos-12 runners have usually managed to run the build
job in less than 3 hours. However, lately, the jobs often end up
taking much longer, over 5 hours, and have ended up exceeding the
6 hour timeout occasionally, even if they still also some times run
in the expected time of less than 3 hours.
Switch to the faster macos-14 runners (which can complete the build
job in around 1 h 40 min), to avoid these timeouts.
This sets the variable CLEAN=1 after building the tools, which makes
all the builds of the runtime libraries remove old build dirs
before building.
This is similar to, but has a slight different purpose than
the existing --wipe-runtimes, which removes the installed runtime
files. Both are useful when testing various build configurations
and investigating issues, for different testing scenarios.
If not building with FULL_LLVM the directory is empty or doesn't exist.
Otherwise it contains the LLVM headers. In either case merge the architecture specific ones into it.
The DWARF debug info should work just as well.
Since 8c03f400a837dc9333e54ab371e7904aa2bec43c in llvm-project,
llvm-symbolizer prefers DWARF over PDB if there is a DWARF section
in the inspected executable. Thus, in order to use PDB, one would
have to strip out any remnants of DWARF debug info from the executable,
like in run-lldb-tests.sh (e.g. by -Wl,-s).
For the purposes of this test, simplifying the setup to use DWARF
works just as well.
When calling make_indirect_call with a parameter which is known,
Clang, since the 18.x release, can end up producing a specialized
version of the function which omits the cfguard check call (as the
target is known) and calls the known target directly.
The function is marked with a noinline attribute, to avoid
the compiler optimizing out the cfguard check call when the
target is known, but even with a noinline function, the compiler
apparently can make a separate specialized version of it.
To avoid the compiler doing such optimizations, reference the
target function via a global variable - the compiler can't assume
anything about the contents of them (they could be altered between
initialization and reading them later).
This fixes the cfguard invalid_icall test with Clang 18.x, when
compiled with optimizations enabled.
6b6b1240e2 tried to build a
multiplatform image, by building two images separately and pushing
them one at a time, with the same name (but with a different platform).
This doesn't work as expected; the last push for the image name
replaces earlier pushes. So depending on which push finishes
last, we'd end up with either an amd64 or arm64 image, but not
one that supports both.
Instead, push two separate images just with push-by-digest, and
then create the actual tag with "docker buildx imagetools create".
Alternatively, we could build all platform variants of the main
image with Dockerfile.toolchain, simplifying the setup significantly.
The contents of such a build is marginally different though, so
keep the amd64 image as it was, for now, compiled in that environment.
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.
Martin Storsjö