The mingw64 environment is deprecated, which the setup-msys2 action
warns about.
We don't really use the host environment's tools anyway so the
choice doesn't matter. Ideally we maybe would use the msys
environment instead, to avoid accidentally relying on build tools
from there. But if building in the msys environment, ffmpeg things
we're building for msys as opposed to native mingw. (This can
probably be avoided by specifying --target-os though.)
When running tests on Windows with busybox-w32 as shell, removing
the output log file for the stacksmash-asan testcase fails like this
occasionally:
rm: can't remove 'log1-stacksmash-asan': Permission denied
This only seems to happen with the i686 build of busybox-w32, but
happens for the stacksmash-asan test built as either i686 or x86_64.
(If running run-test.sh repeatedly, it seems like the issue either
happens right away on the first iteration, or doesn't happen at all.)
Avoid breaking builds by simply making it ignore errors from this
particular "rm" command.
With arm64ec now being built as arm64x, sharing DLLs with the
regular aarch64 target, we no longer need these options - the
regular libc++.dll/libunwind.dll from $PATH (from the toolchain
bin directory) work for the arm64ec build as well.
This avoids warnings about the actions targeting Node 20.
There is no easily available documentation about whether there are
any other API changes in the newer versions of these actions - in
particular the bump of build-push-action which advances by two
versions.
This reverts commit 5e3f73a650.
As the arm64x support has been reverted, this isn't needed. And
after bumping to LLVM 23.1.0 RC 2, we won't need it anyway.
This reverts commit 64effa9a71.
It turns out that the LLD handling of the TLS data structures
("_tls_used" and "_tls_index") needs more work, causing the
arm64ec side of arm64x binaries to not get them hooked up properly.
With arm64ec now being built as arm64x, sharing DLLs with the
regular aarch64 target, we no longer need these options - the
regular libc++.dll/libunwind.dll from $PATH (from the toolchain
bin directory) work for the arm64ec build as well.
When building throwcatch-main.exe, we link with "-L.". Since we
copy in the runtime libraries for executing tests, we might have
libc++.dll present if we aim for the target "test" while
compiling.
For arm64x builds, we could end up trying to link directly against
the arm64x libc++.dll rather than with the import library. Linking
directly against an arm64x DLL doesn't work yet in 23.1.0-rc1, so
avoid hitting this situation for now.
This is a temporary workaround; linking against an arm64x DLL should
work too, and the fix is being backported to the next RC.
Some notable changes since 22.x:
- Linking a weak declaration against a weak definition now works
properly
- Many improvements for ARM64EC, including supporting linking
against ARM64EC thin libraries
- Support for compiling for ARM64X (files targeting both native
aarch64 and ARM64EC) with the -marm64x flag, which generates
a multi-architecture object file. This should make it much
more feasible, build system wise, to actually build things for
ARM64X.
- Fixed aarch64 branch protection on Windows to use the right
signing key (previously it the wrong one, which was inactive on
Windows, and which broke unwinding in older versions of Wine)
Previously, we added the llvm-mingw bundled python to the head
of PATH, but we didn't expect to use it after all.
(In other tests, where we explicitly want to use the llvm-mingw
bundled python, we set -DPython3_EXECUTABLE="$Env:PYTHON_EXE.)
Previously (with runner image version 20260622.87.1), CMake ended
up choosing
C:/hostedtoolcache/windows/Python/3.13.14/x64/python3.exe, but
now (with runner image version 20260629.93.2) we ended up picking
C:/llvm-mingw/python/bin/python3.14.exe instead.
With the newer runner images, we do have
C:\hostedtoolcache\windows\Python\3.13.14\arm64\python3.exe in
PATH, but it is unclear why that doesn't get picked.
(Picking another version than the first one in PATH would make
sense if we'd have Python_FIND_STRATEGY=VERSION set. According to
the docs, that shouldn't be the default any longer though, and it
wouldn't explain why it picked 3.13 before when we provide
3.14.)
In any case, just skip adding our version to PATH since we
don't intend to use it, to make it use the system provided
version.
This is the newest version currently available in the Ubuntu 24.04
repos.
This fixes building; previously it failed to build libc++, which only
supports being built with one of the two preceding versions of Clang.
This reverts commit 1d8c107d49.
After 49e14021be, when using F(-NAN)
instead of -F(NAN) to hide the negation, this test passes correctly.
I hadn't realized that GCC and Clang optimized cos(-x) = cos(x), when
I made 1d8c107d49 (and at the time, the
F() macro didn't work properly with -NAN on all toolchains).
In the former form, the negation of NAN is hidden inside the
optimization blocking macro/wrapper. After
9be66e9d22, F(-NAN) works just as
well as -F(NAN).
This avoids test issues with recent optimizations in LLVM.
https://github.com/llvm/llvm-project/pull/193586 seems to make
the compiler consider known symmetry for hyperbolic math functions,
exploiting the fact that cosh(-x) is equal to cosh(x) (for values
other than NANs). By hiding the negation inside the F() wrapper,
the compiler can't reason about is existence.
checkout@v5 should be the same as checkout@v4, just running on
Node 24. checkout@v6 has got a few other minor changes that
shouldn't make any difference; opt in to newer behaviours now.
This fixes importing the _ctypes module, if a shared libffi doesn't
happen to exist on the host system with the right so version.
Since Python 3.12, such a build error ends up failing the build,
while it previously passed silently even if some parts of the build
had failed.
This makes sure the openmp tests actually are executed; since
switching to the runtimes build of openmp for the tests (in
98684ab807), the tests weren't
executed, as it no longer found the tools necessary for executing
the tests - as they are expected to be specified differently
in the runtimes build mode.
This requires the commit 48a5119d8e7d7236a28c14d06ec215ef3366ef90
(backported to 22.x in 9794a7932465bdc244b327388905d66df38485e2,
part of the 22.1.1 release) in llvm-project, to be able to run
tests without actually building clang in the same build as the
test tools.
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.
Since 6295b8e763503644961f9087382f80965b98d466 in llvm-project,
it's no longer possible to build openmp entirely standalone;
now one has to build it through the runtimes directory.
This version of mingw-w64 includes the function "mkdtemp", which
breaks building the previously pinned version of busybox-w32 on i686.
Update both projects in sync, so that builds with newer nightly
versions of mingw-w64 also succeed.
Some notable changes since LLVM 21.x related to mingw:
- Handle an uncommon error code in libcxx's std::filesystem,
avoiding spurious test failures if running the libcxx test suite
(noted at least occasionally on Github Actions)
- Reinstate x86 stack probe functions in compiler-rt, that we earlier
beleived weren't used - but turned out to be used by GCC in i386
mode
- Fix interpretation of a few corner case aarch64 SEH unwind opcodes
- Support for FAT LTO (compile with -ffat-lto-objects, link with
-Wl,--fat-lto-objects)
- llvm-objcopy: Support the -p option for COFF targets
- llvm-readobj: A new option --coff-pseudoreloc for dumping information
and symbols for mingw runtime pseudo relocations
- Lots of various fixes for the cygwin target
- Improve linking a custom CRT with binutils ld (by passing the custom
CRT -l option at the same place as the original default -lmsvcrt)
- Make lld use the right mingw specific DLL entry point implicitly,
improving some Rust use cases
- Fix running the libcxx tests with optimization for mingw targets,
allowing more test coverage of the code generation paths
The built-in make is a POSIX make tool, which doesn't support
GNU make features.
As we do have GNU make, insert that as "make.exe" in the busybox
directory. Don't do that in the main llvm-mingw bin directory,
which can be used with other environments (e.g. msys2), where the
native make is to be preferred.
This allows running the built busybox on older versions of
Windows that don't support the utf8 manifest. (The utf8 manifest
is supported since Windows 10 update 1903.)
When building with mingw32-make, it prefers executing commands
through "sh.exe" if it is available.
When busybox sh.exe executes "ar", it prefers executing its own
internal tool over a potential external tool found in $PATH.
(This can be avoided by setting 'export BB_OVERRIDE_APPLETS="ar"',
but as this build of busybox is expected to be used with llvm-mingw,
disable the built-in "ar" tool outright.)
According to https://github.com/mstorsjo/llvm-mingw/issues/533,
if OCaml support is detected and the LLVM OCaml bindings are built,
they are attempted to be installed in a path that require root access.
Martin Storsjö