Bug#996645: kodi: please add support for riscv64
Hi,
On 2021-10-16 19:38, Vasyl Gello wrote:
> Hi Aurelien!
>
> Thanks for the great contribution!
Thanks for your fast answer!
> - I modified debian/rules to pass -DWITH_ARCH=riscv64. It's not clear if
> > that part should go upstream, it seems given we do not have CPU
> > specific optimizations to add in cmake/scripts/linux/ArchSetup.cmake
> > so it's not fully necessary. Please tell me if I am wrong, I'll submit
> > that upstream
>
> The Debian packaging for Debian and upstream are totally different,
> so you can send only cmake/scripts/linux/ArchSetup.cmake part there
> if needed.
Ok, thanks for the feedback. I'll send that part upstream, so that entry
from debian/rules can be dropped.
> >- Patch 0024-add-riscv-compile-defines.patch is coming from upstream and
> > will be in Kodi 20. It conflicts with 0006-fix-s390x-build and
> > 0009-fix-alpha-build patches whichh touch the same files. As 0024 is
> > already upstream and will appear at some point in the Debian package,
> > I have moved the 0006 and 0009 patches after it and "rebased" them as
> > 0025 and 0026.
>
> I must check if 19.x has that patch. As for 20.x nightlies, let me explain my intention below
No, I have only found in the master branch. However I don't know
upstream development enough to know if there are chances this is
backported to the Matrix branch. It has been accepted relatively
recently (end of August).
> >- Patch 0027-link-with-pthread.patch changes the way cmake handles
> > Thread support to correctly link with -pthread instead of -lpthread.
> > That way GCC automatically pulls in -latomic if needed. I have noticed
> > that debian/rules already forces LDFLAGS to contain -latomic, however
> > it appears too early in the linker command to be early (it needs to be
> > after the objects needing this library).
>
> Does it apply to other architectures? I recall I had to fix "-latomic" stuff in
> KissFFT…
Unfortunately no. Note however that riscv64 behaves differently than
other architectures wrt libatomic, as it has native support for 32-bit
and 64-bit atomics. It however lacks 1-bit atomics.
> >If you are fine with this patch, could you please consider applying it
> >in the future uploads? If you aren't, do not hesitate to comment, ask
> >for more details or ask for changes to the patch
>
> Do you expect to have this in 19.x or 20.x? Right now, I would like to have 19.x
> propagated across unstable, testing, stable and oldstable-backports.
I was initially expecting to have this in 19.x, as it seems that 20.x
will not be realeased before many months. However I understand that it
causes maintainability issues on your side, so that can perfectly wait
for 20.x. It would be nice to have it in 19.x if it happens that
bookworm still ship with 19.x though.
> However, I don't know if SRM accept changes of every upcoming bugfix release,
> so I try to keep debdiffs for 19.x as small as possible. Of course there might be
> a solution by diverting +deb11u1 but let's get 19.2 into stable first.
Yes, the patch I sent you is definitely not acceptable for stable.
> As for 20.x, I will be building unofficial repo for stable-backports and unstable/testing,
> and there we can experiment as we like.
Ok thanks. Do you have a rough idea when is 20.x planned?
Regards,
Aurelien
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: