sigmaris
Posts: 6
Joined: Sun May 29, 2016 6:21 pm

Some kodi-audiodecoder add-on packages incorrectly linked

Thu Mar 07, 2019 9:42 pm

Some of the kodi-audiodecoder-* packages in Raspbian aren't working for me and seem to have linking problems or something missing in the binaries.

I've installed kodi-audiodecoder-snesapu, when trying to play .spc files with it, Kodi exits with this error logged:

Code: Select all

kodi-standalone[1431]: /usr/lib/arm-linux-gnueabihf/kodi/kodi-rbpi_v7: symbol lookup error: /usr/lib/arm-linux-gnueabihf/kodi/addons/audiodecoder.snesapu/audiodecoder.snesapu.so.2.0.0: undefined symbol: spc_new
A similar thing happens with kodi-audiodecoder-gme:

Code: Select all

kodi-standalone[993]: /usr/lib/arm-linux-gnueabihf/kodi/kodi-rbpi_v7: symbol lookup error: /usr/lib/arm-linux-gnueabihf/kodi/addons/audiodecoder.gme/audiodecoder.gme.so.2.0.0: undefined symbol: gme_open_file
I've checked with ldd and there doesn't seem to be any missing dynamically linked libraries:

Code: Select all

ldd /usr/lib/arm-linux-gnueabihf/kodi/addons/audiodecoder.snesapu/audiodecoder.snesapu.so.2.0.0
	linux-vdso.so.1 (0x7ee0b000)
	/usr/lib/arm-linux-gnueabihf/libarmmem.so (0x76eb0000)
	libp8-platform.so.2 => /usr/lib/arm-linux-gnueabihf/libp8-platform.so.2 (0x76e87000)
	libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x76e5e000)
	libstdc++.so.6 => /usr/lib/arm-linux-gnueabihf/libstdc++.so.6 (0x76d16000)
	libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x76c97000)
	libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0x76c6a000)
	libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76b2b000)
	/lib/ld-linux-armhf.so.3 (0x76edb000)
So I think there's a problem with how these packages are being built. Are the source code and build scripts available for them? Is there somewhere other than this forum to report bugs against Raspbian packages?

Rascas
Posts: 461
Joined: Tue Mar 11, 2014 6:18 pm
Location: Porto, Portugal
Contact: Website

Re: Some kodi-audiodecoder add-on packages incorrectly linked

Thu Mar 07, 2019 11:52 pm

I am the RPi Foundation repo Kodi packages maintainer and you have more information about it here:
viewtopic.php?f=66&t=192499

About how addons are built (and the rest of the packages) is here:
https://github.com/PIPplware/xbmc/blob/ ... ackages.sh

I have to admit it, I don't test this audiodecoder packages (specially this exotic ones) for some time now, I will try them on the weekend.

Thanks for the warning and if you have some ideas or fixes, feel free to submit a pull request in that github.

sigmaris
Posts: 6
Joined: Sun May 29, 2016 6:21 pm

Re: Some kodi-audiodecoder add-on packages incorrectly linked

Sat Mar 09, 2019 5:16 pm

Rascas: I investigated this issue today, the problem is that the binary add-on packages are built with the -DUSE_LTO=1 flag to cmake, but then "ar" and "ranlib" from the binutils package are used on the built libraries, and they do not understand the use of LTO. ar and ranlib print "plugin needed to handle lto object" warnings during the build, and the result is missing symbols as I described.

It seems that when enabling LTO, using "gcc-ar", "gcc-ranlib" and "gcc-nm" is necessary instead of plain "ar", "ranlib", etc. One patch that I tried that fixes the problem is to tell CMake to use these by giving it a CMAKE_TOOLCHAIN_FILE.

I have built the various packages with this patch: https://github.com/PIPplware/xbmc/compa ... ns_lto_fix and it fixes the linking problems, and the built addons work properly and play audio in Kodi. However this patch wouldn't work if the build is a cross-compile - it would only work for people compiling on a Pi with the host GCC, so I'm not sure if this is OK for inclusion in your build script. Let me know if it would be useful and I can submit it as a pull request.

Rascas
Posts: 461
Joined: Tue Mar 11, 2014 6:18 pm
Location: Porto, Portugal
Contact: Website

Re: Some kodi-audiodecoder add-on packages incorrectly linked

Sat Mar 09, 2019 6:36 pm

sigmaris wrote:
Sat Mar 09, 2019 5:16 pm
Rascas: I investigated this issue today, the problem is that the binary add-on packages are built with the -DUSE_LTO=1 flag to cmake, but then "ar" and "ranlib" from the binutils package are used on the built libraries, and they do not understand the use of LTO. ar and ranlib print "plugin needed to handle lto object" warnings during the build, and the result is missing symbols as I described.

It seems that when enabling LTO, using "gcc-ar", "gcc-ranlib" and "gcc-nm" is necessary instead of plain "ar", "ranlib", etc. One patch that I tried that fixes the problem is to tell CMake to use these by giving it a CMAKE_TOOLCHAIN_FILE.

I have built the various packages with this patch: https://github.com/PIPplware/xbmc/compa ... ns_lto_fix and it fixes the linking problems, and the built addons work properly and play audio in Kodi. However this patch wouldn't work if the build is a cross-compile - it would only work for people compiling on a Pi with the host GCC, so I'm not sure if this is OK for inclusion in your build script. Let me know if it would be useful and I can submit it as a pull request.
Thanks for taking a lok at that. It is a bit strange. Most binary addons, like for example, the visualizations, inputstream and some pvrs use LTO by default and work fine. But for example pvr.hts has it disabled because, supposedly, it causes issues with GCC, although that was with an old GCC version:
https://github.com/kodi-pvr/pvr.hts/com ... cffaa8bb1b

I will take a better look, but if the problem is really the LTO enabled, it is probably easier to just disable it for audiodecoders/audioencoders. I believe LibreELEC does not use LTO in any package by default.

Return to “Raspbian”