-
Notifications
You must be signed in to change notification settings - Fork 42
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
Rectify the inability to compile due to an excessively new version of the compilation toolchain. #252
base: Nexus
Are you sure you want to change the base?
Conversation
gcc 13 moved some includes around and as a result <cstdint> is no longer transitively included [1]. Explicitly include it for uint{32,64}_t. [1] https://gcc.gnu.org/gcc-13/porting_to.html#header-dep-changes Signed-off-by: Rudi Heitbaum <[email protected]>
This is from FFmpeg commit effadce6c756247ea8bae32dc13bb3e6f464f0eb . Author: Rémi Denis-Courmont <[email protected]> Date: Sun Jul 16 18:18:02 2023 +0300 avcodec/x86/mathops: clip constants used with shift instructions within inline assembly Fixes assembling with binutil as >= 2.41 Signed-off-by: James Almer <[email protected]> Refs xbmc#164
The header commit is fine. However the bin-utils patch is not. There will be millions of different Linux installs for the current stable release and this patch could break them. Sorry, buts it’s too risky. I recommend comping with ffmpeg6 on the Omega dev branch as this likely already runs with your binutils version. Note that we don’t carry any patches for Linux platforms for ffmpeg. It took us quite a while to get there. I’d prefer not to go back to having them. |
However, the patch to fix https://gitlab.archlinux.org/archlinux/packaging/packages/kodi |
If you are using ffmpeg 6 there should be no reason to compile it yourself. The system one should work ok (hopefully). |
If I use ffmpeg4.4, I don't need to compile it either, but indeed, the last time I compiled inputstream.ffmpegdirect for Omega, I encountered the same error. It seems that FindFFMPEG.cmake has also malfunctioned. The only good news is, after some adjustments, my modifications took effect, and at least now I can compile the packages for Nexus. It seems that if inputstream.ffmpegdirect does not malfunction, the Nexus version can also use the local ffmpeg6?
Upon executing a downgrade, I have discerned that the compilation can still proceed smoothly, implying the absence of substantial difficulties Moreover, if the FindFFMPEG.cmake could work properly, this patch wouldn't be much of a use, but on the contrary, I believe that fixing errors is better than not fixing them. Plus, this is merely a backport of the official ffmpeg patch. The risk is relatively small given that the ffmpeg team has already reviewed the code. And I guess if the new version of inputstream.ffmpegdirect fails to compile, compiling the old version should not be an issue. Also, do you have any ideas on the testing and fixing of FindFFMPEG.cmake? |
No description provided.