Solved Failing to build Kodi Matrix 19.4 on Raspberry Pi 2 - cmake issues
#1
Hi,

noticed the folks at LibreELEC released 10.0.3 based on Kodi 19.4. Tested it and liked it - planning to move from Kodi 17.4 ... finally.

Now, LibreELEC is wonderful but useless to me, first because I need to patch Kodi - to be able to simulate a "shut down" through the shutdown timer (hacking the power management source code) and then I might need some other services running on that box, which are really hard to implement on LE (I'm also not a Debian user).

Studied a little the build script on LE and here is what I tried:
- OS - Slackware Linux 15 ARM - 32bit - GCC 11.2
- Source code:
Kodi 19.4  both GIT snapshot from 25.10.2022 and the actual 19.4 release tag (March 2022)
- patches applied:
https://github.com/LibreELEC/LibreELEC.t...tches/kodi
- deps  I had to satisfy (these were the only ones required extra for Kodi 19.4  (and not for Kodi 18.9))
spdlog (1.10.0)
gtest (1.10.0)
- the way I build Kodi 19.4:
 
Code:
export PATH="$PATH:/opt/java/bin"
export C_INCLUDE_PATH=/opt/vc/include:/opt/vc/include/interface/vcos/pthreads
export CPLUS_INCLUDE_PATH=/opt/vc/include:/opt/vc/include/interface/vcos/pthreads
CFLAGS="$CFLAGS -DEGL_NO_X11"
CXXFLAGS="$CXXFLAGS -DEGL_NO_X11"
cmake ../xbmc -DCMAKE_INSTALL_PREFIX=/usr/local \
-DENABLE_INTERNAL_CROSSGUID=ON \
-DENABLE_INTERNAL_FLATBUFFERS=ON \
-DENABLE_INTERNAL_FMT=ON \
-DCORE_SYSTEM_NAME=linux \
-DWITH_CPU=cortex-a7 \
-DCMAKE_C_FLAGS="-march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard" \
-DCMAKE_CXX_FLAGS="-march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard" \
-DENABLE_AVAHI=OFF \
-DENABLE_PLIST=OFF \
-DENABLE_AIRTUNES=OFF \
-DENABLE_AIRTUNES=OFF \
-DENABLE_UPNP=OFF \
-DENABLE_NEON=ON \
-DENABLE_VDPAU=OFF \
-DENABLE_VAAPI=OFF \
-DENABLE_INTERNAL_FFMPEG=OFF \
-DCORE_PLATFORM_NAME=gbm \
-DAPP_RENDER_SYSTEM=gles \
-DENABLE_GBM=ON \
-DENABLE_ALSA=ON \
-DENABLE_PULSEAUDIO=ON \
-DENABLE_CEC=OFF \
-DENABLE_OPTICAL=OFF \
-DENABLE_BLURAY=OFF \
-DENABLE_LIRCCLIENT=ON \
-DCMAKE_PREFIX_PATH=/opt/vc

Results:
 
Code:
In file included from /usr/include/spdlog/spdlog.h:12,
                 from /KODI-19/xbmc/xbmc/utils/log.h:25,
                 from /KODI-19/xbmc/xbmc/interfaces/legacy/Exception.h:12,
                 from /KODI-19/xbmc/xbmc/interfaces/legacy/Addon.h:13,
                 from /KODI-19/xbmc/xbmc/interfaces/python/PythonInvoker.h:12,
                 from /KODI-19/xbmc/xbmc/network/httprequesthandler/python/HTTPPythonInvoker.h:11,
                 from /KODI-19/xbmc/xbmc/network/httprequesthandler/python/HTTPPythonInvoker.cpp:9:
/usr/include/spdlog/common.h:158:30: error: ‘format_string’ in namespace ‘fmt’ does not name a template type

.....

In file included from /usr/include/spdlog/details/registry-inl.h:12,
                 from /usr/include/spdlog/details/registry.h:114,
                 from /usr/include/spdlog/spdlog.h:13,
                 from /KODI-19/xbmc/xbmc/utils/log.h:25,
                 from /KODI-19/xbmc/xbmc/interfaces/legacy/Exception.h:12,
                 from /KODI-19/xbmc/xbmc/interfaces/legacy/Addon.h:13,
                 from /KODI-19/xbmc/xbmc/interfaces/python/PythonInvoker.h:12,
                 from /KODI-19/xbmc/xbmc/network/httprequesthandler/python/HTTPPythonInvoker.h:11,
                 from /KODI-19/xbmc/xbmc/network/httprequesthandler/python/HTTPPythonInvoker.cpp:9:
/usr/include/spdlog/logger.h:88:53: error: ‘format_string_t’ has not been declared

....

In file included from /usr/include/spdlog/spdlog.h:12,
                 from /KODI-19/xbmc/xbmc/utils/log.h:25,
                 from /KODI-19/xbmc/xbmc/interfaces/legacy/Exception.h:12,
                 from /KODI-19/xbmc/xbmc/interfaces/legacy/Addon.h:13,
                 from /KODI-19/xbmc/xbmc/interfaces/python/PythonInvoker.h:12,
                 from /KODI-19/xbmc/xbmc/network/httprequesthandler/python/HTTPPythonInvoker.h:11,
                 from /KODI-19/xbmc/xbmc/network/httprequesthandler/python/HTTPPythonInvoker.cpp:9:
/usr/include/spdlog/common.h: In instantiation of ‘struct spdlog::is_convertible_to_any_format_string<const std::__cxx11::basic_string<char>&>’:
/usr/include/spdlog/logger.h:106:96:   required by substitution of ‘template<class T, typename std::enable_if<(! spdlog::is_convertible_to_any_format_string<const T&>::value), int>::type <anonymous> > void spdlog::logger::log(spdlog::source_loc, spdlog::level::level_enum, const T&) [with T = std::__cxx11::basic_string<char>; typename std::enable_if<(! spdlog::is_convertible_to_any_format_string<const T&>::value), int>::type <anonymous> = <missing>]’
/usr/include/spdlog/logger.h:102:12:   required from ‘void spdlog::logger::log(spdlog::level::level_enum, const T&) [with T = std::__cxx11::basic_string<char>]’
/KODI-19/xbmc/xbmc/utils/log.h:186:25:   required from ‘void CLog::FormatAndLogInternal(spdlog::level::level_enum, const Char*, Args&& ...) [with Char = char; Args = {const char*&}]’
/KODI-19/xbmc/xbmc/utils/log.h:83:39:   required from ‘static void CLog::Log(spdlog::level::level_enum, const Char*, Args&& ...) [with Char = char; Args = {const char*&}]’
/KODI-19/xbmc/xbmc/utils/log.h:68:8:   required from ‘static void CLog::Log(int, const Char*, Args&& ...) [with Char = char; Args = {const char*&}]’
/KODI-19/xbmc/xbmc/utils/log.h:213:14:   required from here
/usr/include/spdlog/common.h:187:123: error: incomplete type ‘spdlog::is_convertible_to_basic_format_string<const std::__cxx11::basic_string<char>&, char>’ used in nested name specifier
  187 | struct is_convertible_to_any_format_string : std::integral_constant<bool, is_convertible_to_basic_format_string<T, char>::value ||
      |                                                                                                                           ^~~~~
/usr/include/spdlog/common.h:188:130: error: incomplete type ‘spdlog::is_convertible_to_basic_format_string<const std::__cxx11::basic_string<char>&, wchar_t>’ used in nested name specifier
  188 |                                                                               is_convertible_to_basic_format_string<T, wchar_t>::value>
      |                                                                                                                                  ^~~~~
gmake[2]: *** [build/network/httprequesthandler/python/CMakeFiles/network_httprequesthandlers_python.dir/build.make:76: build/network/httprequesthandler/python/CMakeFiles/network_httprequesthandlers_python.dir/HTTPPythonInvoker.cpp.o] Error 1
gmake[2]: Leaving directory '/KODI-19/kodi-build'
gmake[1]: *** [CMakeFiles/Makefile2:10201: build/network/httprequesthandler/python/CMakeFiles/network_httprequesthandlers_python.dir/all] Error 2
gmake[1]: *** Waiting for unfinished jobs....

Any help appreciated!
Reply
#2
Two things as a heads up for now...

- LibreELEC does have its own support forum where you should get more direct and detailed answers from its own developers
- Logs of any kind are preferred to be presented via a pastebin website. Simply to keep own web/forum servers clean.
Reply
#3
- I don't use LibreELEC - the error occurs by building the official Kodi source code - besides - the patches I applied are not related to the compilation crash
- the small log snippet I considered appropriate for a post format

I'd be thankful if people were trying to help on the actual issue.
Reply
#4
use ENABLE_INTERNAL_SPDLOG if you are going to use ENABLE_INTERNAL_FMT.
The failure is its using a system spdlog that doesnt support features.
Reply
#5
(2022-10-26, 07:32)abga Wrote: I don't use LibreELEC

Oops, sorry... I guess there was still some soup in my eyes this early.
Reply
#6
@Fuzzard 

Thanks for the quick reply and fix. I didn't know that -DENABLE_INTERNAL_FMT=ON requires -DENABLE_INTERNAL_SPDLOG=ON, it didn't for Kodi 18.x
I grabbed the source code for spdlog and built it manually because of the cmake error message I got with only -DENABLE_INTERNAL_FMT=ON, which was:
Code:
CMake Error at cmake/modules/FindSpdlog.cmake:62 (find_package):
  Could not find a package configuration file provided by "spdlog" (requested
  version 1.5.0) with any of the following names:

    spdlogConfig.cmake
    spdlog-config.cmake

  Add the installation prefix of "spdlog" to CMAKE_PREFIX_PATH or set
  "spdlog_DIR" to a directory containing one of the above files.  If "spdlog"
  provides a separate development package or SDK, be sure it has been
  installed.

I removed my spdlog compilation (package) now and instructed the Kodi build scripts to build spdlog internally as per your advice with both directives:
-DENABLE_INTERNAL_FMT=ON \
-DENABLE_INTERNAL_SPDLOG=ON \

I got over the reported compilation crash (which was at ~ 4%) and ran into an out of memory issue at ~ 6% with 3 make jobs:
Code:
[  6%] Building CXX object build/windowing/gbm/drm/CMakeFiles/windowing_gbm_drm.dir/DRMAtomic.cpp.o
[  6%] Building CXX object build/network/httprequesthandler/python/CMakeFiles/network_httprequesthandlers_python.dir/HTTPPythonWsgiInvoker.cpp.o
...

- htop "ASCII" screenshot:

    1[||||||||||                                                                                                 8.2%] Tasks: 66, 0 thr, 106 kthr; 1 running
    2[|||||||||||||||||||                                                                                       16.1%] Load average: 10.70 7.85 4.83
    3[||||||||                                                                                                   6.5%] Uptime: 6 days, 15:25:14
    4[|||||||                                                                                                    6.0%] Disk IO: 83.7% read: 25.3M write: 0K
  Mem[||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||869M/965M]
  Swp[||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||198M/200M]

I restarted the compilation with only 2 make jobs and ended up with another compilation crash - apparently in /xbmc/windowing/gbm/WinSystemGbmEGLContext.cpp:90:11
Code:
[  6%] Building CXX object build/windowing/gbm/CMakeFiles/windowing_gbm.dir/WinSystemGbmEGLContext.cpp.o
cd /KODI-19/kodi-build/build/windowing/gbm && /usr/bin/ccache /usr/bin/c++ -DHAS_NEON -I/KODI-19/xbmc -I/KODI-19/xbmc/lib -I/KODI-19/xbmc/xbmc -I/KODI-19/xbmc/xbmc/platform/linu
In file included from /usr/include/c++/11.2.0/map:60,
                 from /KODI-19/xbmc/xbmc/windowing/gbm/drm/DRMPlane.h:13,
                 from /KODI-19/xbmc/xbmc/windowing/gbm/drm/DRMUtils.h:14,
                 from /KODI-19/xbmc/xbmc/windowing/gbm/drm/DRMAtomic.h:11,
                 from /KODI-19/xbmc/xbmc/windowing/gbm/drm/DRMAtomic.cpp:9:
/usr/include/c++/11.2.0/bits/stl_tree.h: In member function ‘std::pair<std::_Rb_tree_node_base*, std::_Rb_tree_node_base*> std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_M_get_insert_hint_unique_pos(std::_Rb_tree<_Key, _Val,
/usr/include/c++/11.2.0/bits/stl_tree.h:2161:5: note: parameter passing for argument of type ‘std::_Rb_tree<unsigned int, std::pair<const unsigned int, long long unsigned int>, std::_Select1st<std::pair<const unsigned int, long long unsi
 2161 |     _Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[  6%] Building CXX object build/windowing/gbm/drm/CMakeFiles/windowing_gbm_drm.dir/DRMConnector.cpp.o
cd /KODI-19/kodi-build/build/windowing/gbm/drm && /usr/bin/ccache /usr/bin/c++ -DHAS_NEON -I/KODI-19/xbmc -I/KODI-19/xbmc/lib -I/KODI-19/xbmc/xbmc -I/KODI-19/xbmc/xbmc/platform/
/KODI-19/xbmc/xbmc/windowing/gbm/WinSystemGbmEGLContext.cpp: In member function ‘virtual bool KODI::WINDOWING::GBM::CWinSystemGbmEGLContext::CreateNewWindow(const string&, bool, RESOLUTION_INFO&)’:
/KODI-19/xbmc/xbmc/windowing/gbm/WinSystemGbmEGLContext.cpp:90:11: error: invalid conversion from ‘khronos_uintptr_t’ {aka ‘long unsigned int’} to ‘EGLNativeWindowType’ {aka ‘void*’} [-fpermissive]
   90 |           reinterpret_cast<khronos_uintptr_t>(m_GBM->GetDevice()->GetSurface()->Get())))
      |           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |           |
      |           khronos_uintptr_t {aka long unsigned int}
In file included from /KODI-19/xbmc/xbmc/windowing/gbm/WinSystemGbmEGLContext.h:12,
                 from /KODI-19/xbmc/xbmc/windowing/gbm/WinSystemGbmEGLContext.cpp:9:
/KODI-19/xbmc/xbmc/utils/EGLUtils.h:192:70: note:   initializing argument 2 of ‘bool CEGLContextUtils::CreatePlatformSurface(void*, EGLNativeWindowType)’
  192 |   bool CreatePlatformSurface(void* nativeWindow, EGLNativeWindowType nativeWindowLegacy);
      |                                                  ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~
gmake[2]: *** [build/windowing/gbm/CMakeFiles/windowing_gbm.dir/build.make:118: build/windowing/gbm/CMakeFiles/windowing_gbm.dir/WinSystemGbmEGLContext.cpp.o] Error 1
gmake[2]: Leaving directory '/KODI-19/kodi-build'
gmake[1]: *** [CMakeFiles/Makefile2:5016: build/windowing/gbm/CMakeFiles/windowing_gbm.dir/all] Error 2
gmake[1]: *** Waiting for unfinished jobs....

Inspecting /xbmc/windowing/gbm/WinSystemGbmEGLContext.cpp:90:11 I l learned that there's some sort of conditional checking - verifying the "platform header files" age - whatever "platform" means in the head of the dev that wrote that comment ...
Code:
  // This check + the reinterpret cast is for security reason, if the user has outdated platform header files which often is the case
  static_assert(sizeof(EGLNativeWindowType) == sizeof(gbm_surface*), "Declaration specifier differs in size");

  if (!m_eglContext.CreatePlatformSurface(
          m_GBM->GetDevice()->GetSurface()->Get(),
          reinterpret_cast<khronos_uintptr_t>(m_GBM->GetDevice()->GetSurface()->Get())))
  {
    return false;
  }

Now, in CMakeCache.txt I learned that the Kodi build script linked to the EGL libraries from /opt/vc (as intended)
Code:
//Path to a file.
EGL_INCLUDE_DIR:PATH=/opt/vc/include
//Path to a library.
EGL_LIBRARY:FILEPATH=/opt/vc/lib/libEGL.so
//Path to a library.
pkgcfg_lib_PC_EGL_EGL:FILEPATH=/opt/vc/lib/libEGL.so
And the userland in /opt/vc is fresh - downloaded and compiled on 25.10.2022 from:
https://github.com/raspberrypi/userland

On my system I have mesa 21.3.5 built with vc4 support and I couldn't figure out what version the folks at LibreELEC used - glxinfo is not available and they symlinked /opt/vc/lib with /usr/lib.
Just for some extra details - my actual mesa is built according to this script:
http://ftp.arm.slackware.com/slackwarear...SlackBuild

Is there a minimum mesa version requirement for Kodi 19.4? I might be able to build & install a newer mesa, although it's a huge PITA to build mesa on ARM ... I have a script here for mesa 22.2.2 that I could adapt/use:
http://ftp.arm.slackware.com/slackwarear...SlackBuild

@Klojum 

NP, it was early in the morning Wink
Reply
#7
Its not required, but spdlog depends on fmt, and there are ABI breakages. Kodi has a direct dependency on both Spdlog and fmt, so if you build fmt only, and the spdlog you provide is linked to a fmt that isnt compatible, theres your breakage.

I'll step out from here on out, i dont deal with anything RPI. maybe @popcornmix can provide some pointers
Reply
#8
OK, so I tried a few other things:

1. commented the whole conditional checking from line 90 in /xbmc/windowing/gbm/WinSystemGbmEGLContext.cpp and got over that error. Smile

2. But then I got into a different (next in the build process, percentage-wise close to the first at ~ 7%) error related to GLES
Code:
/usr/include/GLES3/gl3.h:1065:9: error: typedef ‘GLsync’ is initialized (use ‘decltype’ instead)
 1065 | typedef GLsync (GL_APIENTRYP PFNGLFENCESYNCPROC) (GLenum condition, GLbitfield flags);
      |         ^~~~~~
/usr/include/GLES3/gl3.h:1065:30: error: ‘PFNGLFENCESYNCPROC’ was not declared in this scope; did you mean ‘PFNGLISFENCENVPROC’?
 1065 | typedef GLsync (GL_APIENTRYP PFNGLFENCESYNCPROC) (GLenum condition, GLbitfield flags);
      |                              ^~~~~~~~~~~~~~~~~~
      |                              PFNGLISFENCENVPROC
.....
gmake[2]: *** [build/windowing/gbm/CMakeFiles/windowing_gbm.dir/build.make:160: build/windowing/gbm/CMakeFiles/windowing_gbm.dir/WinSystemGbmGLESContext.cpp.o] Error 1

I'm using now two different GLES instances - pointing the Kodi cmake scripts to: "-- Found OpenGLES: /opt/vc/lib/libGLESv2.so" and then gbm using the system mesa with its own GLES - notice "/usr/include/GLES3/" in the error above.
Since MMAL & OMX  shouldn't be used anymore in Kodi 19.x for RPI - I hid the /opt/vc folder and removed all the directives pointing to /opt/vc from the cmake configuration.

Ended up with this stupid cmake config error now:
Code:
-- Found TinyXML: /usr/lib/libtinyxml.so
-- Found ZLIB: /usr/lib/libz.so (found version "1.2.13")
CMake Error at /usr/share/cmake-3.21/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find EGL (missing: EGL_LIBRARY) (found version "1.5")
Call Stack (most recent call first):
  /usr/share/cmake-3.21/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
  cmake/modules/FindEGL.cmake:30 (find_package_handle_standard_args)
  cmake/scripts/common/Macros.cmake:354 (find_package)
  cmake/scripts/common/Macros.cmake:368 (find_package_with_ver)
  CMakeLists.txt:184 (core_require_dep)


-- Configuring incomplete, errors occurred!

Stupid because: "   Could NOT find EGL (missing: EGL_LIBRARY) (found version "1.5")"

Just recalled this discussion where @HiassofT and @popcornmix helped:
https://forum.kodi.tv/showthread.php?tid=357229&page=2
and with this new experience I'm afraid that the support for RPI - and the new shiny gbm implementation is still a "work in progress" in Kodi and there are maybe some other undocumented hacks to build it.
Reply
#9
Kodi 19 has no pi specific code and doesn't support the firmware 3d driver.
You need to remove any reference to /opt/vc in the build, and use standard mesa (arm side) libraries for 3d.

This may be a better starting point for building than LibreELEC.
Reply
#10
Thanks @popcornmix for your inputs. I was aware about the thread you presented, been following it every now and then just to check the progress on gbm. Unfortunately it's  focusing on your work "git clone -b gbm_matrix https://github.com/popcornmix/xbmc.git kodi_gbm" and has specific RPIOS info - pretty useless when it comes to versioning (apt-get & apt-don't-get latest libs/deps which are difficult to investigate on version & config options(build scripts)).
I've been using LE to test the progress - mainly PVR playback and noticed that LE 10 finally plays everything smooth - considered to replicate the LE build (patches & co) but using the official Kodi instructions from here:
https://github.com/xbmc/xbmc/blob/Matrix...berryPi.md
https://github.com/xbmc/xbmc/blob/Matrix...E.Linux.md

It turns out that my version of cmake - 3.21.4 - for whatever reason doesn't pick up the system mesa libEGL & libGLESv2 libs from /usr/lib and I had to add the following directives to the cmake configuration block:
 
Code:
-DEGL_LIBRARY=/usr/lib/libEGL.so \
-DOPENGLES_gl_LIBRARY=/usr/lib/libGLESv2.so \
-DOPENGLES_INCLUDE_DIR=/usr/include/GLES2 \

Learned about these online - plenty of hits - from others struggling to build Qt ...

Successfully built Kodi 19.4 - 25.10.2022 git snapshot now, although the compilation crashed at 80% - out of memory with 2 make jobs and then I had to continue it (hopefully the build remained consistent) with only 1 make job. Took around 15 hours on a Pi2B.
I'm wondering if I'll need to rent an ARM VPS (if such exists) with gigabytes of RAM online to compile Kodi 20 Smile Pi4 are still unavailable here in EU (well, available in some places overpriced).
Kodi 18.9 was still build-able with 3 make jobs in 965MB RAM (32MB video mem).

On the Pi specific code:
- I built FFmpeg externally because I wanted to patch it with the LE patches and use the same version as LE - FFmpeg-4.3.2-Matrix-19.1
Patches applied:
 
Code:
patch -p1 < patches/ffmpeg-001-libreelec.patch
patch -p1 < patches/ffmpeg-001-v4l2-drmprime.patch
From here:
https://github.com/LibreELEC/LibreELEC.t...eg/patches

- Kodi I patched with:
 
Code:
patch -p1 < KODI-19PATCHES/kodi-001-deinterlace.patch
patch -p1 < KODI-19PATCHES/kodi-002-set-max-bpc-for-high-bit-depth-videos.patch
patch -p1 < KODI-19PATCHES/kodi-003-add-colourspace-connector-property.patch
patch -p1 < KODI-19PATCHES/kodi-004-deinterlace-swdecode.patch
From here:
https://github.com/LibreELEC/LibreELEC.t...tches/kodi

And only this particular patch:
https://github.com/LibreELEC/LibreELEC.t...lock.patch
from here:
https://github.com/LibreELEC/LibreELEC.t...di/patches


Will need to play & test now the build, hoping it'll work just fine.
Reply
#11
Hurray! It crashes! Smile

Actually it crashes the box - kernel.
Here the kernel log - very precious as I only managed to grab it once, usually Kodi freezes the system without any log entries:
https://pastebin.pl/view/0586ce2b

It's a Raspberry Zero 2 W - LE 10 runs nice on it (FullHD content), even with 512 MB RAM.

First I noticed that kodi will shout (console) that it cannot find some vc4 vulkan libs - wondered why is it looking after:
 
Code:
MESA-LOADER: failed to open vc4: libvulkan.so.1: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)
failed to load driver: vc4
MESA-LOADER: failed to open kms_swrast: libvulkan.so.1: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)
failed to load driver: kms_swrast
MESA-LOADER: failed to open swrast: libvulkan.so.1: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)
failed to load swrast driver
ERROR: Unable to create GUI. Exiting
My /usr/lib/dri/ doesn't contain any vulkan stuff.

Then noticed in the kodi.log that there are some issues with DRM:
 
Code:
2022-10-28 23:10:37.997 T:2225    ERROR <general>: CWinSystemGbm::InitWindowSystem - failed to initialize Atomic DRM
2022-10-28 23:10:38.001 T:2225    ERROR <general>: CWinSystemGbm::InitWindowSystem - failed to initialize Legacy DRM
2022-10-28 23:10:38.258 T:2225    ERROR <general>: CGBMUtils::CreateDevice - failed to create device: No such file or directory
2022-10-28 23:10:38.785 T:2225    FATAL <general>: CApplication::CreateGUI - unable to init windowing system

Spent a lot of time inspecting MESA, even recompiled the whole libdrm crap to make sure I have vc4 support. Just afterwards I learned that those Atomic DRM & Legacy DRM entries are also popping up in the LE 10 Kodi log.

Well, the folks at LE are wise, using an older kernel:
 
Code:
LibreELEC:~/.kodi/temp # uname -r
5.10.110

Don't know what to do next. A kernel upgrade is in sight, mainly due to the recent WiFi exploits. But I'm not yet sure when I'll get the time for it. I need to build the kernel myself because I need to patch some DVB drivers and enable some extra networking stuff.
Also not sure why LE is using such an old kernel and if the latest Raspberry kernel (source) is working - maybe I'll get into the same issues like with my actual one.

Will put a lid on this (can of worms) for now I guess. Back to the good ol' Kodi 17.4, the only one usable on Raspberries - due to the audio-video sync issues in Kodi18.x with analogue audio and MMAL (OMX is useless - hangs on every channel switch on PVR).

Besides, anecdotally, I was the one (under a different nickname - since Jamesh hates abga) asking the Raspberry devs to fix the dumb audio generation in the GPU:
https://forums.raspberrypi.com/viewtopic...0#p1818105

At that time I had a 1400x900 monitor on my desk and was happy with their resolve. Didn't consider to hook a Pi to one of the FullHD TVs to make sure it's fixed - on those TVs I use.HDMi audio (digital).
Now I switched to a FullHD monitor and analogue audio is crackling again like crazy (almost unusable). They moved the audio generation algo on a different GPU core (used for de-interlacing) and I'm not sure there's something extra left to try. Amusing how some extra few hundred lines (FullHD) overwhelmed again the GPU... actually sad.
Reply
#12
@popcornmix  - it's here I can address you directly, lost the credentials for the Raspberry forum and I'm not registered with github. Finally it's still on subject - not off topic.
I spent some more time trying to start Kodi 19.4 on one of my Pi Zero 2 Ws, learned that it's maybe a kernel&firmware (mesa libs?) issue and not that much Kodi's fault.

Steps I've done:
- took the latest kernel code from https://github.com/raspberrypi/linux - 5.15.76-v7 - Nov. 2  git snapshot, patched a DVB frontend and built it.
- also took the latest firmware (a week ago):
 
Code:
# /opt/vc/bin/vcgencmd version
Oct 26 2022 11:10:35
Copyright (c) 2012 Broadcom
version c72ad6b26ff40c91ef776b847436094ee63fabee (clean) (release) (start)
- created an advancedsettings.xml - turned on the debug and launched kodi with strace and the screen on (framebuffer dirver). Kodi started, turned the screen off and exited - without crashing the system/kernel this time. This Kodi debug log snippet is relevant:
 
Code:
2022-11-02 21:14:18.380 T:4770    DEBUG <general>: CApplication::CreateGUI - trying to init gbm windowing system
2022-11-02 21:14:18.507 T:4786    DEBUG <general>: Thread libinput start, auto delete: false
2022-11-02 21:14:18.507 T:4770     INFO <general>: RetroPlayer[PROCESS]: Registering process control for GBM
2022-11-02 21:14:18.507 T:4770     INFO <general>: RetroPlayer[RENDER]: Registering renderer factory for DMA
2022-11-02 21:14:18.507 T:4770     INFO <general>: RetroPlayer[RENDER]: Registering renderer factory for OpenGLES
2022-11-02 21:14:18.509 T:4770    DEBUG <general>: CDRMUtils::OpenDrm - drm devices found: 1
2022-11-02 21:14:18.511 T:4770    DEBUG <general>: CDRMUtils::FindConnector - failed to find connected connector
2022-11-02 21:14:18.511 T:4770    ERROR <general>: CWinSystemGbm::InitWindowSystem - failed to initialize Atomic DRM
2022-11-02 21:14:18.512 T:4770    DEBUG <general>: CDRMUtils::OpenDrm - drm devices found: 1
2022-11-02 21:14:18.513 T:4770    DEBUG <general>: CDRMUtils::FindConnector - failed to find connected connector
2022-11-02 21:14:18.514 T:4770    ERROR <general>: CWinSystemGbm::InitWindowSystem - failed to initialize Legacy DRM
2022-11-02 21:14:18.515 T:4770    DEBUG <general>: CDRMUtils::OpenDrm - drm devices found: 1
2022-11-02 21:14:18.516 T:4770    DEBUG <general>: CDRMUtils::OpenDrm - opened device: /dev/dri/card0
2022-11-02 21:14:18.516 T:4770    DEBUG <general>: CDRMUtils::PrintDrmDeviceInfo - DRM Device Info:
                                                     available_nodes: 0x05
                                                     nodes:
                                                       nodes[0]: /dev/dri/card0
                                                       nodes[2]: /dev/dri/renderD128
                                                     bustype: 0x02
                                                       platform:
                                                         fullname: /soc/gpu
2022-11-02 21:14:18.516 T:4770    DEBUG <general>: CDRMUtils::OpenDrm - opened render node: /dev/dri/renderD128
2022-11-02 21:14:18.516 T:4770    DEBUG <general>: COffScreenModeSetting::InitDrm - initialized offscreen DRM
2022-11-02 21:14:18.551 T:4770    ERROR <general>: CGBMUtils::CreateDevice - failed to create device: No such file or directory
2022-11-02 21:14:18.551 T:4770    DEBUG <general>: CApplication::CreateGUI - unable to init gbm windowing system
2022-11-02 21:14:18.551 T:4770    DEBUG <general>: CWinSystemGbm::DestroyWindowSystem - deinitialized DRM
....
2022-11-02 21:14:18.878 T:4786    DEBUG <general>: Thread libinput 1274015856 terminating
2022-11-02 21:14:19.320 T:4770    FATAL <general>: CApplication::CreateGUI - unable to init windowing system
- kodi console output:
 
Code:
MESA-LOADER: failed to open vc4: libvulkan.so.1: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)
failed to load driver: vc4
MESA-LOADER: failed to open kms_swrast: libvulkan.so.1: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)
failed to load driver: kms_swrast
MESA-LOADER: failed to open swrast: libvulkan.so.1: cannot open shared object file: No such file or directory (search paths /usr/lib/dri, suffix _dri)
failed to load swrast driver
ERROR: Unable to create GUI. Exiting
- kernel output (dmesg):
 
Code:
[ 1117.907285] [drm:drm_crtc_commit_wait [drm]] *ERROR* flip_done timed out
[ 1117.907737] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CRTC:89:crtc-3] commit wait timed out
- strace relevant snippet:
 
Code:
ioctl(0, DRM_IOCTL_MODE_SETCRTC, 0x7e8dae98) = 0
write(9, "2022-11-02 21:14:44.579 T:1553  "..., 107) = 107
ioctl(0, DRM_IOCTL_AUTH_MAGIC, 0x7e8dafbc) = -1 EINVAL (Invalid argument)
close(28)                               = 0
close(0)                                = 0
write(9, "2022-11-02 21:14:44.582 T:1553  "..., 109) = 109
write(2, "ERROR: Unable to create GUI. Exi"..., 37) = 37

Then, started Kodi again (strace) and this time both strace and the kernel log had more interesting entries:
- strace:
- there were plenty (pages) of DRM_IOCTL_MODE_GETPROPERTY & DRM_IOCTL_MODE_GETPROPBLOB with 0 results
- last relevant line - again, just before Kodi exiting:
 
Code:
ioctl(0, DRM_IOCTL_AUTH_MAGIC, 0x7edb0f94) = -1 EINVAL (Invalid argument)
- the kernel threw this time the entire block:
 
Code:
[ 1128.147280] [drm:drm_crtc_commit_wait [drm]] *ERROR* flip_done timed out
[ 1128.147733] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [CONNECTOR:32:HDMI-A-1] commit wait timed out
[ 1138.387290] [drm:drm_crtc_commit_wait [drm]] *ERROR* flip_done timed out
[ 1138.387757] [drm:drm_atomic_helper_wait_for_dependencies [drm_kms_helper]] *ERROR* [PLANE:79:plane-3] commit wait timed out
[ 1148.627281] [drm:drm_crtc_commit_wait [drm]] *ERROR* flip_done timed out
[ 1148.627737] vc4-drm soc:gpu: [drm] *ERROR* Timed out waiting for commit
[ 1158.867295] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:89:crtc-3] flip_done timed out

Noticed that this is an actual bug that you considered recently resolved:
https://github.com/raspberrypi/linux/issues/4962

Apparently is not - and in my case it doesn't even apply to the monitor being in suspend mode, even when it's on I hit this issue.
Some others are also complaining and focusing on the kernel:
https://bugzilla.redhat.com/show_bug.cgi?id=2008557

Tried to add to cmdline your suggested fix video=HDMI-A-1Big Grin without any positive results.
Then I took and loaded the firmware from LE 10.0.3, again, no success.
I replicated the config.txt directives from LE 10.0.3:
 
Code:
hdmi_ignore_cec_init=1
display_auto_detect=1
gpu_mem=76
dtoverlay=vc4-kms-v3d
disable_overscan=1
disable_fw_kms_setup=1
with no improvement.
I also commented gpu_mem=76 and played with dtoverlay=vc4-kms-v3d,cma-256 & dtoverlay=vc4-kms-v3d,cma-512 - useless.
/dev/dri/card0 and /dev/dri/renderD128 are both belonging to the video group and kodi (user) belongs to that group too.

I'm not experienced with this DRM & GBM stuff - and don't really understand why Kodi is failing to start the GUI - from the strace log it looks like the kernel driver doesn't give a "beep" about Kodi (through the libs) trying to communicate/probe with it (DRM_IOCTL_MODE_GETPROPERTY & DRM_IOCTL_MODE_GETPROPBLOB).

Any help appreciated!
Reply
#13
(2022-11-03, 05:32)abga Wrote: ERROR: Unable to create GUI. Exiting
You would probably be better off confirming that you have a working drm/kms install.
Try running modetest (you should be able to change hdmi mode and display a framebuffer with test patterns with it).
kmscube is another useful, simple test which includes 3d displayed through drm (very similar to kodi).

Also you haven't confirmed but make sure you are launching from a text console.
If you have an X windowing system running, then you can't launch any other drm code (there can be only one drm master).
Switching to a text tty (e.g. with ctrl-alt-F3) allows X to drop being the drm master and allow other code to use drm.
Quote:Noticed that this is an actual bug that you considered recently resolved:
https://github.com/raspberrypi/linux/issues/4962
"Flip done timeout" is the error you get from any failure (on any drm platform).
It just means we submitted a frame and it didn't report that it completed.
There are a million possible reasons for this, and the bug you found is almost certainly unrelated
(it specifically relates to switching the display off, which you aren't doing).
Reply
#14
@popcornmix 
Thank you again for your quick reply and help.
I was already worried in post #6 that my mesa might not be OK (version/patches/build options) - an I mean specifically for the Raspberry (vc4) requirements (current development).
KMS I believe it's solely a kernel implementation (driver), DRM is both kernel (DRM) and libs (mesa - DRI).
On the system I have apparently a newer mesa than what is used in Debian Bullseye:
 
Code:
$ cat /var/log/packages/mesa-21.3.5-arm-2 | grep vc4
usr/lib/dri/vc4_dri.so
$ ls -al /usr/lib/dri/vc4_dri.so
-rwxr-xr-x 36 root root 21774212 Jan 29  2022 /usr/lib/dri/vc4_dri.so*
LE 10.0.3 has the same file available, only 8MB big (mine is 21MB):
 
Code:
LibreELEC:~ # ls -al /lib/dri/vc4_dri.so
-rwxr-xr-x   22 root     root       8450152 Oct 15 03:22 /lib/dri/vc4_dri.so

Bullseye is using apparently an older mesa 20.3.5-1
https://sources.debian.org/src/mesa/
The source folder looks useless for inspiration on how it was built for arm 32 hard float (Raspberry).
https://sources.debian.org/src/mesa/20.3.5-1/

I might be able to use an unorthodox tool and convert Debian packages to Slackware packages, uninstall my system mesa and install the converted package - hoping not to break things.
But I couldn't find a repository where I could download the actual RaspiOS 32 bit arm HF mesa deb file.
Honestly, these Debian & Ubuntu derivatives are all opaque to me (not that much "open source" apparently - too much automation - almost M$ Windows like), no versioning on packages, no idea how to trace back the packages and inspect how these were built, no repos to browse file manually, etc...

I'll perform the tests you suggested. But I doubt on any success - looks like I need to replicate Debian Bullseye/RaspiOS mesa first.

I do launch Kodi from text console, X is not even configured. As said, I'm focusing to dedicate the Pi only for Kodi.

P.S. found a Raspbian (not sure is the same as RaspiOS) repo that has a Bullseye folder ... containing Packages.gz (i presume it's an archived list of packages).
https://raspbian.mirror.uk.sargasso.net/...ary-armhf/

Any instructions on how to grab a RaspiOS package without running Debian/RaspiOS would be really helpful.

P.P.S. It appears that Debian is splitting mesa in (many) smaller packages and it's difficult to gather all together manually.
https://packages.debian.org/bullseye/libs/
https://packages.debian.org/bullseye/libs/libegl-mesa0
.. etc.

I called this effort previously a "can of worms" and it appears I wasn't wrong. I guess  the official Kodi doc should be corrected form "Linux build guide" to "Debian and derivatives build guide":
https://github.com/xbmc/xbmc/blob/Matrix...E.Linux.md

Will try to rebuild an older mesa (on par with the one in RaspiOS) on my own, but it's a PITA because it has a lot of poorly documented build options and some patches I don't know if applicable.
Reply
#15
(2022-11-04, 01:08)abga Wrote: @popcornmix 
Thank you again for your quick reply and help.
I was already worried in post #6 that my mesa might not be OK (version/patches/build options) - an I mean specifically for the Raspberry (vc4) requirements (current development).
KMS I believe it's solely a kernel implementation (driver), DRM is both kernel (DRM) and libs (mesa - DRI).
On the system I have apparently a newer mesa than what is used in Debian Bullseye:
I believe building mesa from source using head of upstream mesa tree doesn't break RPiOS, so I don't expect your issue will be due to a too new version of mesa.
Reply

Logout Mark Read Team Forum Stats Members Help
Failing to build Kodi Matrix 19.4 on Raspberry Pi 2 - cmake issues0