-
Notifications
You must be signed in to change notification settings - Fork 415
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FFmpeg Linux binaries: Include version in file name #6153
FFmpeg Linux binaries: Include version in file name #6153
Conversation
Before: `libavutil.so` etc. Now: `libavutil.so.56` etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ugh this stinks...
- Does ffmpeg not do backports at all?
- Is this patch going to work for
binutils
<2.41? The commit message doesn't say, but we build the images on github actions on ubuntu 20.04, and as per https://packages.ubuntu.com/search?keywords=binutils, it'll be 2.34 on there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know. I don't exactly like adding the responsibility of maintaining patchfiles to the project. But while the FFmpeg project does release patches to older versions, I couldn't find a 4.3 or even 4.X-compatible release with this fix.
And yes, this will work on older versions. The if (__builtin_constant_p(shift))
is used to check whether the old code can be used or not. To make sure, here's a build from the PR branch. (this is the line confirming the patch)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another possible solution would be updating FFmpeg to 6.1. That would require some working around an unfixed bug in the framework code, but it would also avoid this kind of patching. (this issue tracks the path to a 5.X upgrade, and there hasn't been movement on FFmpeg's side for a while)
I've been playing around with using newer FFmpeg versions (>=5.0) in osu-framework and I noticed that FFmpeg.AutoGen had a major API change at some point. Edit (disregard previous comment version): The API has changed, but it looks like there are still ways to get more control over library loading (it looks like it's even possible to delete the Linux workaround regarding RTLD_GLOBAL. Note for later: It looks like it's possible to inject a custom FunctionResolver before Initialize is called, which actually seems nicer than the current GetOrLoadLibrary API. |
I explain the rationale behind this change in #6154.
The included patch is necessary for local builds on some distros, and it will become necessary on more distros (and CI) as binutils gets updated (ver 2.41 breaks the ffmpeg build).
Note that the new NativeLibs version will cause the current logic to not find the new libraries. See the linked PR for the required logic change.