ARM and Win32 fail to build

[nihil-admirari]

https://github.com/yt-dlp/FFmpeg-Builds/actions/runs/10228496022/job/28301131257

ARM logs:

2024-08-03T14:07:35.0639506Z #48 12.18 error: unknown warning option '-Werror=maybe-uninitialized'; did you mean '-Werror=uninitialized'? [-Werror,-Wunknown-warning-option]

Win32 logs are more problematic. The first issue is apparently:

2024-08-03T14:22:05.3207287Z #90 0.733 /usr/bin/m4:aclocal.m4:1194: cannot open `m4/libtool.m4': No such file or directory
2024-08-03T14:22:05.3208707Z #90 0.736 /usr/bin/m4:aclocal.m4:1195: cannot open `m4/ltoptions.m4': No such file or directory
2024-08-03T14:22:05.3210207Z #90 0.740 /usr/bin/m4:aclocal.m4:1197: cannot open `m4/ltversion.m4': No such file or directory
2024-08-03T14:22:05.3211341Z #90 1.011 autom4te: error: /usr/bin/m4 failed with exit status: 1

Other errors follow:

2024-08-03T14:26:02.1605936Z #69 824.1 collect2: error: ld returned 1 exit status
2024-08-03T14:26:02.1607716Z #69 824.1 make[2]: *** [test/vvencinterfacetest/CMakeFiles/vvencinterfacetest.dir/build.make:101: /50-vvenc/bin/release-static/vvencinterfacetest.exe] Error 1
2024-08-03T14:26:02.1609777Z #69 824.1 make[1]: *** [CMakeFiles/Makefile2:302: test/vvencinterfacetest/CMakeFiles/vvencinterfacetest.dir/all] Error 2

[BtbN]

The first error is caused by clang simply not knowing that option.
Not sure how to deal with that, I think I won't fully support the winarm64 builds until gcc support is there, which luckily isn't thaaat far away anymore.

The other error is a bit more baffling. It's failing at a part that's not even different per-arch, it's just generating the configure script.
It's also passing everywhere else. Are you sure your images are all intact? Maybe clear the cache and do a full rebuild.

[nihil-admirari]

It builds now: https://github.com/yt-dlp/FFmpeg-Builds/actions/runs/10236737758.

[nihil-admirari]

ARM builds are failing once again:

2024-08-10T14:52:31.6357461Z #58 35.12 /50-libzmq/src/clock.cpp:251:48: error: use of undeclared identifier 'nsecs_per_usec'; did you mean 'usecs_per_sec'?
2024-08-10T14:52:31.6359164Z #58 35.13   251 |     return static_cast<uint64_t> (ts.tv_sec) * nsecs_per_usec * usecs_per_sec
2024-08-10T14:52:31.6360273Z #58 35.13       |                                                ^~~~~~~~~~~~~~
2024-08-10T14:52:31.6361153Z #58 35.13       |                                                usecs_per_sec
2024-08-10T14:52:31.6362376Z #58 35.13 /50-libzmq/src/clock.cpp:106:16: note: 'usecs_per_sec' declared here
2024-08-10T14:52:31.6363422Z #58 35.13   106 | const uint64_t usecs_per_sec = 1000000;
2024-08-10T14:52:31.6364136Z #58 35.13       |                ^
2024-08-10T14:52:31.6364724Z #58 35.39 1 error generated.

[BtbN]

This looks like a straight up upstream bug to me: zeromq/libzmq@a02cbd0
Seems like it doesn't think aarch64 can be Windows.

[BtbN]

I'm actually thinking about retiring the partial win-on-arm support again.
The rust toolchain for it also broke in random and spectacular ways, and there is no documentation or obvious ways to talk to anyone in the know about that exotic target.
So for now I will not fix any more issues cropping up with that target.

[nihil-admirari]

It did it again https://github.com/yt-dlp/FFmpeg-Builds/actions/runs/10441150459/job/28911974601:

2024-08-18T14:12:23.5946888Z #66 5.123 Error: CliError { error: Some("/opt/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/Cargo.lock" does not exist, unable to build with the standard library, try:
2024-08-18T14:12:23.5949486Z #66 5.124         rustup component add rust-src --toolchain nightly-x86_64-unknown-linux-gnu), exit_code: 101 }

[BtbN]

Yes, rust broke their ability to build for win-on-aarch64 somehow. Haven't yet figured out how to fix this sadly.
It almost looks like they plain forgot to include that file it's complaining about after some update of some component. Cause rust-src is explicitly installed in the winarm64 base image.

I also tried using the pre-compiled toolchain instead, but that then fails with other errors cause rust is passing invalid arguments to clang then.

[nihil-admirari]

Is there a Rust issue tracking this?

[BtbN]

I don't even know where that issue would be tracked, I haven't found where rust-src is coming from.
The issue about the invalid clang args is fixed upstream at cc-rs, but since the rust folks pin all their dependencies, there's a lot of other packages that now need to update their pins until things actually become usable again.

Opened an issue about that with rav1e, but no reaction. Development seems stalled.

[nihil-admirari]

rust-src is Rust standard library, and if I'm not mistaken it's located in the main Rust repo: https://github.com/rust-lang/rust/tree/master/library/std.

The issue IMHO should be opened in The Rust toolchain installer repository: https://github.com/rust-lang/rustup. I haven't done it myself, since I'm not aware of all the details.

[nihil-admirari]

https://github.com/yt-dlp/FFmpeg-Builds/actions/runs/10526879428/job/29168922602

2024-08-23T14:13:38.2255589Z #62 189.7 warning: rav1e@0.7.0: ToolExecError: Command "aarch64-w64-mingw32-clang" "-O3" "--target=aarch64-pc-windows-gnullvm" "-ffunction-sections" "-fdata-sections" "-gdwarf-2" "-fno-omit-frame-pointer" "--target=aarch64-pc-windows-gnullvm" "-I" "." "-I" "/50-rav1e/target/aarch64-pc-windows-gnullvm/release/build/rav1e-c2389fd6a3b533c7/out" "-I/opt/ffbuild/include" "-O2" "-pipe" "-D_FORTIFY_SOURCE=2" "-fstack-protector-strong" "-o" "/50-rav1e/target/aarch64-pc-windows-gnullvm/release/build/rav1e-c2389fd6a3b533c7/out/ca81b3637afdb6b5-cdef.o" "-c" "src/arm/64/cdef.S" with args aarch64-w64-mingw32-clang did not execute successfully (status code exit status: 1).cargo:warning=clang: error: version 'llvm' in target triple 'aarch64-pc-windows-gnullvm' is invalid

[BtbN]

Yes, that is the other error it switched to when using the pre-built toolchain.
It's fixed in upstream cc-rs: rust-lang/cc-rs#1176
But since the rust-world pins everything, until each and every project, including rav1e itself, updates the pinned version of cc-rs, building for win-on-arm will be broken with latest clang.
I don't see a good way to fix this other than disabling rav1e entirely for that target.

[Andarwinux]

Is there a Rust issue tracking this?

see rust-lang/rust#128808

They thought they fixed the problem, they didn't, the only working solution was to pin the entire toolchain to nightly-2024-07-30.

[BtbN]

There's working pre-built toolchains for the windows aarch64 target now, so luckily it doesn't matter anymore here.
I'm forcefully updating cc-rs for rav1e now, so it should build again.

[nihil-admirari]

Win32 builds did it again:

2024-09-21T14:04:07.2193664Z libavcodec/vulkan_encode_h264.c: In function 'create_session_params':
2024-09-21T14:04:07.2203289Z libavcodec/vulkan_encode_h264.c:1051:43: error: initialization of 'long long unsigned int' from 'void *' makes integer from pointer without a cast [-Wint-conversion]
2024-09-21T14:04:07.2205006Z  1051 |         .videoSessionParametersTemplate = NULL,
2024-09-21T14:04:07.2205719Z       |                                           ^~~~
2024-09-21T14:04:07.2210613Z libavcodec/vulkan_encode_h264.c:1051:43: note: (near initialization for '(anonymous).videoSessionParametersTemplate')

[BtbN]

That's a bug in ffmpeg itself though, it should use the Vulkan-Null-Type, cause it uses an entirely different type on 32 bit Windows.

[nihil-admirari]

How does it look like in code? Vulkan-Null-Type is not valid C.

[nihil-admirari]

Ok, found it myself https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/vulkan_av1.c#L225:

        .videoSessionParametersTemplate = VK_NULL_HANDLE,

[nihil-admirari]

Sent a fix to ffmpeg-devel: https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2024-September/333751.html.

[nihil-admirari]

A different patch got merged instead: FFmpeg/FFmpeg@2bcc124.