Skip to content
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

Open
wants to merge 2 commits into
base: Nexus
Choose a base branch
from

Conversation

daiaji
Copy link

@daiaji daiaji commented Sep 29, 2023

No description provided.

heitbaum and others added 2 commits September 30, 2023 01:22
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
@daiaji daiaji changed the title Fix the compilation failure caused by an excessively new toolchain. Rectify the inability to compile due to an excessively new version of the compilation toolchain. Sep 30, 2023
@phunkyfish
Copy link
Collaborator

phunkyfish commented Sep 30, 2023

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.

@daiaji
Copy link
Author

daiaji commented Oct 3, 2023

I recommend comping with ffmpeg6 on the Omega dev branch as this likely already runs with your binutils version.

However, the patch to fix src/libavcodec/x86/mathops.h:125: Error: operand type mismatch for 'shr' is still not applied to xbmc's ffmpeg6. Consequently, this patch remains necessary for a successful compilation.

https://gitlab.archlinux.org/archlinux/packaging/packages/kodi
On a side note, the official source of Arch Linux has also adopted this patch.

@phunkyfish
Copy link
Collaborator

I recommend comping with ffmpeg6 on the Omega dev branch as this likely already runs with your binutils version.

However, the patch to fix src/libavcodec/x86/mathops.h:125: Error: operand type mismatch for 'shr' is still not applied to xbmc's ffmpeg6. Consequently, this patch remains necessary for a successful compilation.

https://gitlab.archlinux.org/archlinux/packaging/packages/kodi On a side note, the official source of Arch Linux has also adopted this patch.

If you are using ffmpeg 6 there should be no reason to compile it yourself. The system one should work ok (hopefully).

@daiaji
Copy link
Author

daiaji commented Oct 4, 2023

I recommend comping with ffmpeg6 on the Omega dev branch as this likely already runs with your binutils version.

However, the patch to fix src/libavcodec/x86/mathops.h:125: Error: operand type mismatch for 'shr' is still not applied to xbmc's ffmpeg6. Consequently, this patch remains necessary for a successful compilation.
https://gitlab.archlinux.org/archlinux/packaging/packages/kodi On a side note, the official source of Arch Linux has also adopted this patch.

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?

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.

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants