This avoids failing if building in an environment where texinfo
exists, but is a newer version. (Support for texinfo 7.1 and 7.2
was added in ffmpeg 8.0.)
Ubuntu 26.04 contains a version of texinfo that fails to build
the docs in ffmpeg 6.0.2. The "ubuntu-latest" runners on Github
Actions are now running on Ubuntu 26.04.
7z is included in the list of officially supported/included
applications on the Github Actions Windows images, so we can
rely on it.
This can be significantly faster than the Expand-Archive command,
see e.g. https://github.com/PowerShell/PowerShell/issues/3355.
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.
Extend the aarch64-w64-mingw32 prefix to provide ARM64EC libraries
alongside standard AArch64 libraries, replacing the separate
arm64ec-w64-mingw32 prefix. This aligns with how MSVC distributes
ARM64EC libraries and enables the linker to process both targets
simultaneously into a single hybrid binary.
This extensively utilizes LLVM's -marm64x option, compiling both
targets in a single compiler invocation to produce hybrid object
files (unlike MSVC tools, which require separate compilation passes).
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.
Extend the aarch64-w64-mingw32 prefix to provide ARM64EC libraries
alongside standard AArch64 libraries, replacing the separate
arm64ec-w64-mingw32 prefix. This aligns with how MSVC distributes
ARM64EC libraries and enables the linker to process both targets
simultaneously into a single hybrid binary.
This extensively utilizes LLVM's -marm64x option, compiling both
targets in a single compiler invocation to produce hybrid object
files (unlike MSVC tools, which require separate compilation passes).
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).
Martin Storsjö