Since 6295b8e763503644961f9087382f80965b98d466 in llvm-project,
one no longer can configure the openmp project entirely standalone,
one has to do it through the runtimes directory.
However, in practice, this currently leads to no tests being
executed at all, as the runtimes build setup doesn't support
pointing to an external FileCheck executable - it currently has
to be part of a full bootstrapping build.
These builds fail regularly, under mysterious circumstances.
("The hosted runner lost communication with the server. Anything
in your workflow that terminates the runner process, starves it
for CPU/Memory, or blocks its network access can cause this error.")
This usually seems to happen around the build-libcxx.sh step.
For some unknown reason, macos-15 runners (which macos-latest
resolves to currently) seem to be consistently 25-40% slower than
macos-14 runners; the "macos" job (doing an universal binary build
for 2 architectures, with LTO) often take over 5 hours, and have
reached the 6 hour timeout once.
Switch this back to macos-14 to speed it up and reduce the risk of
hitting the timeout.
In the future, if/when the macos-14 runners are phased out, and if
the performance reduction in macos-15 runners remains, we'd need to
switch to building each architecture in a separate job, and merge
them together separately if we still want to provide universal
binaries.
The ARM github actions runners now run on Windows 11 10.0.26100,
which no longer support executing armv7 binaries. (Previously they
were running Windows 11 10.0.22631.)
Using Frontend instrumentation rather than IR. This gives less
total speedup, but makes the profile much more usable for cross
other build targets.
Build the full Linux toolchain in stage1; this avoids needing to
rebuild runtimes for doing the profiling in stage2, and avoids
needing to wait for stage3 to complete before cross building
for Windows.
This requires setting CMAKE_CXX_COMPILER_TARGET manually; the LLVM
build system infers the wrong architecture when CMake is an
x86_64 binary.
(The wrong inferred architecture doesn't affect building libcxx,
but the wrong architecture gets passed as --target= parameter
when running the tests.)
Since 9c67ae861ccb0312fc680414a8441892d169d14a in llvm-project
(May 9th), these tests should pass on aarch64 too.
Co-authored-by: Jeremy Drake <github@jdrake.com>
Currently, "macos-latest" gets "macos-14", while there also are
"macos-15" runners available. Switch back to the latest variant
in preparation for that being updated at some point.
This reverts 7bd4b284f9.
Since 3e56f5f41843204b6e612362542b77110f8f8188 in llvm-project,
this should pass for all 4 architectures. (This doesn't pass
in the pinned release version right now.)
This matches what 28851edf164a337c334755ae33fd58f03cffd5a2 in
llvm-project did.
When setting up the built libcxx files for testing, the built
files are installed into a temporary test root, and the install of
them litters the build log with mostly uninteresting output.
This is required for building libffi. With ubuntu-22.04 images,
the libltdl-dev package was available out of the box.
Also explicitly install swig, which we rely on - this also seems
to have been available implicitly.
This fixes building on Ubuntu 24.04 (the one currently used by
the github actions ubuntu-latest tag), by including a fix for texinfo
7.0.
Not bumping to ffmpeg 7.x, as some tests there can be flaky at times.
These days, it seems to be installed out of the box already on the
runner images, and installing it triggers very visible warnings
about it already being installed.
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.
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.
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ö