FFmpeg 5.1 build issues

[lukasf]

FFmpeg 5.1 is out. I tried to build it. Guess what? Getting that stupid linker bug again!! This time it happens only on x64 build, not on x86.

I can build FFmpeg n5.0, n5.0.1, but on n5.1, LINK.exe hangs... Would be great if you could test this on one of your machines, when you are back from holidays @brabebhin.

[brabebhin]

Oh no no no. I think i deleted those vms, but maybe there's a backup somewhere. I will create a new one if needed. I'm back from vacation.

[brabebhin]

Yeah, they are completely gone. Do you have a branch which reproduces this issue?

nvm: found a buggy branch.

[lukasf]

Our branch does not really matter. Just go into Libs\ffmpeg and do git fetch git checkout n5.1 and then run Build-FFmpeg.ps1

[brabebhin]

So it's going to take a while to set up a VM again. in any case, dav1D can't be built with a 32bit machine. I remember we were using the "wrong" linker the first time we had it, maybe we now need to put it back?

[lukasf]

Switching from native x64 compiler to x86 -> x64 cross compiler solved the issue. So this seems to be a problem of 64 bit link.exe. Last time we also had problems when we used the 64 bit x64 -> x86 cross compiler and solved it by going to 32 bit x86 native compiler.

This time I am going to submit this to Microsoft. 32 bit is going to get extinct someday. Windows 11 does not have a 32 bit version (although it has support for 32 bit applications). I wonder how long 32 bit support will be carried on by OS and CPU manufacturers. It's probably still going to be supported for many years, but it feels bad to rely on this in our build system.

[brabebhin]

32 bit apps are probably going to outlive UWP lol. But the majority of 32 bit apps on 64 bit OSes are desktop apps and typically legacy apps. While VS still allows compiling for 32 bits, most new apps are 64 bit by default.

For our use case, i'd say it is complicated: since UWP are store delivered, the possibility of having a 32 bit app on a 64 bit OS is quite slim, since the store automatically installs the most appropriate package. The only way I can see is if someone explicitly does not provide a 64 bit built, or some sort of ARM interop on old Windows Phones.

I am pretty pessimistic on Microsoft fixing this. This probably works for them to eliminate 32 bit apps over time

[lukasf]

You got me wrong. MSVC comes with cross compilers in all directions. So we can have x86 compiler create x64 apps and vice versa. Previously, we used x64 compilers for creating both x86 and x64. Last time we had the bug, we switched to use x86 compiler for x86, even if we are running 64 bits. Now I am switching so we use x86 compiler for both x86 and x64 targets.

This also means that the bug does not help elimintating 32 bits. In the opposite: If they stop providing 32 bit compilers, they need to fix the bug (or we are in trouble).

I think if we can provide a good way to reproduce this, it might get fixed. Now that all prerequisites are installed automatically, it really is just one powershell command to provoke the linker error.

[brabebhin]

Ah ok now I got what you're saying.

For me x86 is also not working with the "old" 64 bit linker I am using Windows 10 though (I seriously dislike the start menu on 11 ^^)