ffmpeg: build failure with binutils 2.41

[oskarirauta]

Maintainer: @thess
Environment: x86_64, latest git

Description:

Build failed, following error repeated numerous times:

Error: operand type mismatch for `shr'

I found a patch for it from here: https://www.linuxquestions.org/questions/slackware-14/regression-on-current-with-ffmpeg-4175727691/ file: https://git.videolan.org/?p=ffmpeg.git;a=patch;h=effadce6c756247ea8bae32dc13bb3e6f464f0eb

I can verify that this patch fixes the issue.

[BKPepe]

I can not see that binutils 2.41 is in the master branch. I double-checked it and in the master branch, there is 2.40. It seems that you are using the latest git also with something else.

You can see that the latest ffmpeg update was successfully compiled on all targets: #22128

In this case as you seems to be using something else then the latest git, I suggest to create pull request with that patch or wait until a new version ffmpeg is released. Also, you can usd binutils 2.40

[oskarirauta]

@BKPepe

What? I am using plain git version.
Check here: https://github.com/openwrt/openwrt/tree/main/toolchain/binutils

There's 2.41. Updated ages ago. Both in main and master branches. I checked it only once though..
Here's the commit: #9194fcb1a4052fd4ead29464d959dee686f8c94c after my second check that there definitely is 2.41...

[BKPepe]

Not used as default version - https://github.com/openwrt/openwrt/blob/587f94eb1adb2eb65ff7b87a78c4641d2d15dc2c/toolchain/binutils/Config.in#L5.

[oskarirauta]

Sure- but so isn't 6.x branch kernel and yet preparation to develop on that branch is on focus... That's what we are moving towards anyway, downgrading happens pretty rarely. Whole point of this is issue is to maintain compatibility with master- even when defaults are not chosen as choosing alternating options shouldn't result in issues, or if it does; someone could attempt to fix it. Otherwise, there should be plenty of options with just title build failure. Out of the box choices are for developers. And developers should try to find problems and fix them. IMHO.

As fun as it is to debate with you, I think it's waste of my time and life's too short, so I won't. I am ending it with simply saying that for those who rather look forward and choose v2.41, fix to newly found issue is linked above.

[thess]

@oskarirauta - Thanks for flagging this issue. Apparently binutils introduced this change in:
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=c34d1cc9200ae24dc7572aaf77d80276c0490e9b
and, the corresponding trac item: https://trac.ffmpeg.org/ticket/10405 documents a patch for mathops.h in libavcodec.

ffmpeg (5.1 branch) fixed on 16-Jul-2023 by:
https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/25cd95a9dc3510c3cc0d7aad6f9d83f6a1078c7e
not yet released but should be in 5.1.4. If you think this is important for now, then submit a PR with the upstream patch with a remark that it can be reverted at the next update to ffmpeg.

[oskarirauta]

@thess

There is a reason why I made this issue instead of PR - I only verified that this fixes build with binutils-2.41, impact with older versions of binutils is un-tested by me. Surely it's important, at least for me, who constantly re-builds images to participate and provide fixes; aim always is to be able to build everything; but I am not using ffmpeg for anything at the moment. Yet, importance exists for those who do. But sure, I'll submit a PR as requested.

PR: #22191

[BKPepe]

Sure- but so isn't 6.x branch kernel and yet preparation to develop on that branch is on focus...

I don't dispute it, of course. Kernel 6.1 is slowly getting integrated into OpenWrt and several targets already have it as testing kernel. There's a difference. In your OP, there were no details on how to reproduce it. You did not say that you weren't used defaults. That's important to know. You just said platform and latest git even though the ffmpeg update was tested and as I pointed out, it was compile tested by CI, which is using the latest commit from each branch (my PR was against master branch, thus it was using the master branch) and buildbots do not report it.

Usually these testing things are not meant to be for end users, but for someone who will provide as much details as possible to be able to reproduce it and as well for developers, who can fix that.

Whole point of this is issue is to maintain compatibility with master- even when defaults are not chosen as choosing alternating options shouldn't result in issues, or if it does; someone could attempt to fix it.

Since you already notice it with all these force push, it is not so easy to fix it instead of creating the issue and complaining that someone else did the job pretty badly, right?

---

In any case, this issue should not be closed as it is not fixed. It will be.