[abga]

Is there any undocumented way to build Kodi 18 natively on a Raspberry Pi2B HardFloat ARM Linux system, that has all the tools and dependencies already available, that's without building an entire OS, like documented in the Kodi official doc? (LibreELEC is already built and a nice system BTW).
I built https://github.com/xbmc/FFmpeg/archive/4...RC5.tar.gz on my own, as shared lib, and tried to follow this doc:
https://github.com/xbmc/xbmc/blob/master...berryPi.md
- executed the following:

Code:

cd /kit/kodi-slack-build/kodi/tools/depends
./bootstrap
./configure --prefix=/kit/kodi-slack-build/kodi/ --with-platform=raspberry-pi2 --disable-debug

- if I run make I'm building a whole darn operating system - stopped after compiling cmake/python 2 & 3 .. etc, around 500MB of binaries that I already have available on my system
- the next step, I omitted running make in the depends subdir and tried to build Kodi after the bootstrap & configure

Code:

/kit/kodi-slack-build/kodi# make -j 3 -C tools/depends/target/cmakebuildsys
make: Entering directory '/kit/kodi-slack-build/kodi/tools/depends/target/cmakebuildsys'
mkdir -p /kit/kodi-slack-build/kodi/build
cd /kit/kodi-slack-build/kodi/build; /kit/kodi-slack-build/kodi/armv7l-linux-gnueabihf-native/bin/cmake -DCMAKE_TOOLCHAIN_FILE=/kit/kodi-slack-build/kodi/raspberry-pi2-release/share/Toolchain.cmake -DCMAKE_INSTALL_PREFIX=/kit/kodi-slack-build/kodi/raspberry-pi2-release -DCMAKE_BUILD_TYPE=Release -DENABLE_INTERNAL_CROSSGUID=OFF -DENABLE_INTERNAL_FFMPEG=OFF  /kit/kodi-slack-build/kodi
/bin/sh: /kit/kodi-slack-build/kodi/armv7l-linux-gnueabihf-native/bin/cmake: No such file or directory
make: *** [Makefile:17: all] Error 127
make: Leaving directory '/kit/kodi-slack-build/kodi/tools/depends/target/cmakebuildsys'

- only to find out that the cmake available on my system is no good and /kit/kodi-slack-build/kodi/armv7l-linux-gnueabihf-native/bin/cmake is called instead (which obviously doesn't exist as I didn't built it)

By trial and error I found out that I have -DCORE_PLATFORM_NAME=rbpi, started to get excited and followed this generic Linux doc ... and failed again:
https://github.com/xbmc/xbmc/blob/master...E.Linux.md

/kit/kodi-slack-build/kodi-build# cmake ../kodi -DCMAKE_INSTALL_PREFIX=/usr/local -DENABLE_INTERNAL_CROSSGUID=ON -DENABLE_INTERNAL_FLATBUFFERS=ON -DENABLE_INTERNAL_FMT=ON -DCORE_PLATFORM_NAME=rbpi

Code:

-- The CXX compiler identification is GNU 8.2.0
-- The C compiler identification is GNU 8.2.0
-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/cc
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Source directory: /kit/kodi-slack-build/kodi
-- Build directory: /kit/kodi-slack-build/kodi-build
-- Generator: Single-configuration: Release (Unix Makefiles)
-- CMake Version: 3.13.3
-- System type: Linux
-- Checking to see if CXX compiler accepts flag -std=c++11
-- Checking to see if CXX compiler accepts flag -std=c++11 - yes
-- Found CXX11: -std=c++11
-- Linker: GNU gold
-- Core system type: linux
-- Platform:
-- CPU: armv7l, ARCH: arm
-- Cross-Compiling: FALSE
-- Execute build artefacts on host: TRUE
-- Depends based build:
-- Could not find hardware support for SSE (missing: _SSE_TRUE _SSE_OK)
-- Could not find hardware support for SSE2 (missing: _SSE2_TRUE _SSE2_OK)
-- Could not find hardware support for SSE3 (missing: _SSE3_TRUE _SSE3_OK)
-- Could not find hardware support for SSSE3 (missing: _SSSE3_TRUE _SSSE3_OK)
-- Could not find hardware support for SSE4.1 (missing: _SSE41_TRUE _SSE41_OK)
-- Could not find hardware support for SSE4.2 (missing: _SSE42_TRUE _SSE42_OK)
-- Could not find hardware support for AVX (missing: _AVX_TRUE _AVX_OK)
-- Could not find hardware support for AVX2 (missing: _AVX2_TRUE _AVX2_OK)
-- NEON optimization enabled
-- Found Git: /usr/bin/git (found version "2.20.1")
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.2")
-- Found Lzo2: /usr/lib/liblzo2.so
-- Found ZLIB: /usr/lib/libz.so (found version "1.2.11")
-- Found PNG: /usr/lib/libpng.so (found version "1.6.36")
-- Found GIF: /usr/lib/libgif.so
-- Found JPEG: /usr/lib/libjpeg.so (found version "62")
-- Found Alsa: /usr/lib/libasound.so (found version "1.1.8")
-- Could NOT find Avahi (missing: AVAHI_CLIENT_LIBRARY AVAHI_COMMON_LIBRARY AVAHI_CLIENT_INCLUDE_DIR AVAHI_COMMON_INCLUDE_DIR)
-- Found Bluetooth: /usr/lib/libbluetooth.so
-- Found Bluray: /usr/lib/libbluray.so (found suitable version "1.0.2", minimum required is "0.9.3")
-- Found CAP: /lib/libcap.so (found version "2.26")
-- Found CCache: /usr/bin/ccache
-- Could NOT find CEC (missing: CEC_LIBRARY CEC_INCLUDE_DIR) (Required is at least version "4.0.0")
-- Found DBus: /usr/lib/libdbus-1.so (found version "1.12.12")
-- Found LCMS2: /usr/lib/liblcms2.so (found version "2.9")
-- Found LircClient: /usr/local/lib/liblirc_client.so
-- Could NOT find MDNS (missing: MDNS_LIBRARY MDNS_INCLUDE_DIR)
-- Could NOT find MicroHttpd (missing: MICROHTTPD_LIBRARY MICROHTTPD_INCLUDE_DIR)
-- Could NOT find NFS (missing: NFS_LIBRARY NFS_INCLUDE_DIR)
-- Found PulseAudio: /usr/lib/libpulse.so (found suitable version "12.2-rebootstrapped", minimum required is "2.0.0")
-- Found PythonLibs: /usr/lib/libpython2.7.so (found suitable version "2.7.15", minimum required is "2.7")
-- Found Python: /usr/include/python2.7
-- Found SmbClient: /usr/lib/libsmbclient.so (found version "0.4.0")
-- Could NOT find Sndio (missing: SNDIO_LIBRARY SNDIO_INCLUDE_DIR)
-- Found UDEV: /usr/lib/libudev.so (found version "220")
-- Found LibXml2: /usr/lib/libxml2.so (found version "2.9.9")
-- Found XSLT: /usr/lib/libxslt.so (found version "1.1.33")
-- Found Plist: /usr/lib/libplist.so (found version "2.0.0")
-- Found ASS: /usr/local/lib/libass.so (found version "0.13.2")
-- Found Cdio: /usr/lib/libcdio.so (found version "2.0.0")
-- Found EXPAT: /usr/lib/libexpat.so (found version "2.2.6")
-- Found CrossGUID: /kit/kodi-slack-build/kodi-build/build/lib/libcrossguid.a (found version "8f399e8bd4")
-- Found UUID: /usr/lib/libuuid.so (found version "2.33.1")
-- Found Curl: /usr/lib/libcurl.so (found version "7.63.0")
-- Found FFMPEG: /usr/local/include (found version "4.0")
-- Found FlatBuffers: /kit/kodi-slack-build/kodi-build/build/bin/flatc (found version "1.9.0")
-- Found Fmt: /kit/kodi-slack-build/kodi-build/build/lib/libfmt.a (found version "5.1.0")
-- Found FreeType: /usr/lib/libfreetype.so (found version "22.1.16")
-- Found FriBidi: /usr/lib/libfribidi.so (found version "1.0.5")
-- Found fstrcmp: /usr/local/lib/libfstrcmp.so (found version "0.7.D001")
-- Found Iconv: /usr/lib/libc.so
-- Found OpenSSL: /usr/lib/libcrypto.so (found version "1.1.1a")
-- Found PCRE: /usr/lib/libpcrecpp.so (found version "8.42")
-- Found RapidJSON: /usr/local/include (found version "1.1.0")
-- Found Sqlite3: /usr/lib/libsqlite3.so (found version "3.26.0")
-- Found TagLib: /usr/lib/libtag.so (found version "1.11.1")
-- Found TinyXML: /usr/lib/libtinyxml.so (found version "2.6.2")
CMake Error at /usr/share/cmake-3.13/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
  Could NOT find OpenGLES (missing: OPENGLES_gl_LIBRARY)
Call Stack (most recent call first):
  /usr/share/cmake-3.13/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE)
  cmake/modules/FindOpenGLES.cmake:37 (find_package_handle_standard_args)
  cmake/scripts/common/Macros.cmake:366 (find_package)
  cmake/scripts/common/Macros.cmake:380 (find_package_with_ver)
  CMakeLists.txt:179 (core_require_dep)


-- Configuring incomplete, errors occurred!
See also "/kit/kodi-slack-build/kodi-build/CMakeFiles/CMakeOutput.log".
See also "/kit/kodi-slack-build/kodi-build/CMakeFiles/CMakeError.log".

- inspecting the CMake error log I found out that the actual issue is related to pthread_create and not about not finding the OPENGLES_gl_LIBRARY
- and what's "/usr/bin/cc -D_ARMEL" doing on a HardFloat ARM system BTW?
/kit/kodi-slack-build/kodi-build/CMakeFiles# cat CMakeError.log

Code:

Determining if the pthread_create exist failed with the following output:
Change Dir: /kit/kodi-slack-build/kodi-build/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/gmake" "cmTC_9d60b/fast"
/usr/bin/gmake -f CMakeFiles/cmTC_9d60b.dir/build.make CMakeFiles/cmTC_9d60b.dir/build
gmake[1]: Entering directory '/kit/kodi-slack-build/kodi-build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_9d60b.dir/CheckSymbolExists.c.o
/usr/bin/cc   -D_ARMEL -DTARGET_RASPBERRY_PI -Wall    -o CMakeFiles/cmTC_9d60b.dir/CheckSymbolExists.c.o   -c /kit/kodi-slack-build/kodi-build/CMakeFiles/CMakeTmp/CheckSymbolExists.c
Linking C executable cmTC_9d60b
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_9d60b.dir/link.txt --verbose=1
/usr/bin/cc -D_ARMEL -DTARGET_RASPBERRY_PI -Wall    -fuse-ld=gold  CMakeFiles/cmTC_9d60b.dir/CheckSymbolExists.c.o  -o cmTC_9d60b
CMakeFiles/cmTC_9d60b.dir/CheckSymbolExists.c.o:CheckSymbolExists.c:function main: error: undefined reference to 'pthread_create'
CMakeFiles/cmTC_9d60b.dir/CheckSymbolExists.c.o:CheckSymbolExists.c:function main: error: undefined reference to 'pthread_create'
collect2: error: ld returned 1 exit status
gmake[1]: *** [CMakeFiles/cmTC_9d60b.dir/build.make:87: cmTC_9d60b] Error 1
gmake[1]: Leaving directory '/kit/kodi-slack-build/kodi-build/CMakeFiles/CMakeTmp'
gmake: *** [Makefile:121: cmTC_9d60b/fast] Error 2

File /kit/kodi-slack-build/kodi-build/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
/* */
#include <pthread.h>

int main(int argc, char** argv)
{
  (void)argv;
#ifndef pthread_create
  return ((int*)(&pthread_create))[argc];
#else
  (void)argc;
  return 0;
#endif
}

Determining if the function pthread_create exists in the pthreads failed with the following output:
Change Dir: /kit/kodi-slack-build/kodi-build/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/gmake" "cmTC_cd2e5/fast"
/usr/bin/gmake -f CMakeFiles/cmTC_cd2e5.dir/build.make CMakeFiles/cmTC_cd2e5.dir/build
gmake[1]: Entering directory '/kit/kodi-slack-build/kodi-build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_cd2e5.dir/CheckFunctionExists.c.o
/usr/bin/cc   -D_ARMEL -DTARGET_RASPBERRY_PI -Wall -DCHECK_FUNCTION_EXISTS=pthread_create   -o CMakeFiles/cmTC_cd2e5.dir/CheckFunctionExists.c.o   -c /usr/share/cmake-3.13/Modules/CheckFunctionExists.c
Linking C executable cmTC_cd2e5
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_cd2e5.dir/link.txt --verbose=1
/usr/bin/cc -D_ARMEL -DTARGET_RASPBERRY_PI -Wall -DCHECK_FUNCTION_EXISTS=pthread_create   -fuse-ld=gold  CMakeFiles/cmTC_cd2e5.dir/CheckFunctionExists.c.o  -o cmTC_cd2e5 -lpthreads
/usr/bin/ld.gold: error: cannot find -lpthreads
CMakeFiles/cmTC_cd2e5.dir/CheckFunctionExists.c.o:CheckFunctionExists.c:function main: error: undefined reference to 'pthread_create'
collect2: error: ld returned 1 exit status
gmake[1]: *** [CMakeFiles/cmTC_cd2e5.dir/build.make:87: cmTC_cd2e5] Error 1
gmake[1]: Leaving directory '/kit/kodi-slack-build/kodi-build/CMakeFiles/CMakeTmp'
gmake: *** [Makefile:121: cmTC_cd2e5/fast] Error 2

-last lines of  CMakeOutput.log:

Code:

Determining if the function pthread_create exists in the pthread passed with the following output:
Change Dir: /kit/kodi-slack-build/kodi-build/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/gmake" "cmTC_4d396/fast"
/usr/bin/gmake -f CMakeFiles/cmTC_4d396.dir/build.make CMakeFiles/cmTC_4d396.dir/build
gmake[1]: Entering directory '/kit/kodi-slack-build/kodi-build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_4d396.dir/CheckFunctionExists.c.o
/usr/bin/cc   -D_ARMEL -DTARGET_RASPBERRY_PI -Wall -DCHECK_FUNCTION_EXISTS=pthread_create   -o CMakeFiles/cmTC_4d396.dir/CheckFunctionExists.c.o   -c /usr/share/cmake-3.13/Modules/CheckFunctionExists.c
Linking C executable cmTC_4d396
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_4d396.dir/link.txt --verbose=1
/usr/bin/cc -D_ARMEL -DTARGET_RASPBERRY_PI -Wall -DCHECK_FUNCTION_EXISTS=pthread_create   -fuse-ld=gold  CMakeFiles/cmTC_4d396.dir/CheckFunctionExists.c.o  -o cmTC_4d396 -lpthread
gmake[1]: Leaving directory '/kit/kodi-slack-build/kodi-build/CMakeFiles/CMakeTmp'


Determining if the function iconv exists passed with the following output:
Change Dir: /kit/kodi-slack-build/kodi-build/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/gmake" "cmTC_88fb2/fast"
/usr/bin/gmake -f CMakeFiles/cmTC_88fb2.dir/build.make CMakeFiles/cmTC_88fb2.dir/build
gmake[1]: Entering directory '/kit/kodi-slack-build/kodi-build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_88fb2.dir/CheckFunctionExists.c.o
/usr/bin/cc   -D_ARMEL -DTARGET_RASPBERRY_PI -Wall -DCHECK_FUNCTION_EXISTS=iconv   -o CMakeFiles/cmTC_88fb2.dir/CheckFunctionExists.c.o   -c /usr/share/cmake-3.13/Modules/CheckFunctionExists.c
Linking C executable cmTC_88fb2
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_88fb2.dir/link.txt --verbose=1
/usr/bin/cc -D_ARMEL -DTARGET_RASPBERRY_PI -Wall -DCHECK_FUNCTION_EXISTS=iconv   -fuse-ld=gold  CMakeFiles/cmTC_88fb2.dir/CheckFunctionExists.c.o  -o cmTC_88fb2 -lc
gmake[1]: Leaving directory '/kit/kodi-slack-build/kodi-build/CMakeFiles/CMakeTmp'

Any hints / help appreciated!

[Rechi]

https://github.com/xbmc/xbmc/blob/master...berryPi.md

This is only for cross compiling, not for directly building on the Raspberry Pi.

By trial and error I found out that I have -DCORE_PLATFORM_NAME=rbpi, started to get excited and followed this generic Linux doc ... and failed again:
https://github.com/xbmc/xbmc/blob/master...E.Linux.md

/kit/kodi-slack-build/kodi-build# cmake ../kodi -DCMAKE_INSTALL_PREFIX=/usr/local -DENABLE_INTERNAL_CROSSGUID=ON -DENABLE_INTERNAL_FLATBUFFERS=ON -DENABLE_INTERNAL_FMT=ON -DCORE_PLATFORM_NAME=rbpi

Yes you are right, you have to follow https://github.com/xbmc/xbmc/blob/master...E.Linux.md.
Additionally pass -DCMAKE_PREFIX_PATH=/opt/vc. Maybe there are more arguments needed.

[abga]

Thanks for the help!

I knew that:
https://github.com/xbmc/xbmc/blob/master...berryPi.md
Is for cross-compilation,  but it was the only doc I could find that had some references to:
--with-platform=raspberry-pi & --with-platform=raspberry-pi2

I did provide all the needed environmental settings for the compiler with:

Code:

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
LDFLAGS="-L/opt/vc/lib/"

and that's why I didn't believe that my error is /opt/vc related. But since you good people have wrapped everything in cmake now, my compiler flags had no effect.

I followed your advice and added: -DCMAKE_PREFIX_PATH=/opt/vc - it works!
My last apparently working build line looks like this - compiling natively on Rpi 2B with 3 make jobs (29%) as I'm writing this post:

Code:

cmake ../kodi -DCMAKE_INSTALL_PREFIX=/usr/local -DCMAKE_PREFIX_PATH=/opt/vc -DENABLE_INTERNAL_CROSSGUID=ON -DENABLE_INTERNAL_FLATBUFFERS=ON -DENABLE_INTERNAL_FMT=ON -DCORE_SYSTEM_NAME=linux -DCORE_PLATFORM_NAME=rbpi

Worth to mention that in my first attempt, after adding  -DCMAKE_PREFIX_PATH=/opt/vc , I got into this error:

Code:

/usr/include/GLES3/gl3.h:1178:84: error: ‘GLint64’ has not been declared
GL_APICALL void GL_APIENTRY glGetBufferParameteri64v (GLenum target, GLenum pname, GLint64 *params);
                                                                                    ^~~~~~~
gmake[2]: *** [build/swig/CMakeFiles/python_binding.dir/build.make:131: build/swig/CMakeFiles/python_binding.dir/AddonModuleXbmcgui.i.cpp.o] Error 1
gmake[2]: Leaving directory '/kit/kodi-slack-build/kodi-build'
gmake[1]: *** [CMakeFiles/Makefile2:11683: build/swig/CMakeFiles/python_binding.dir/all] Error 2
gmake[1]: *** Waiting for unfinished jobs....

Found out that this is an old Kodi issue, wrongly linking the mesa libs for the Raspberry target gave me some headaches also while building Kodi 17, and by following this thread, I went on and uninstalled the system provided mesa libs - will put them back after the compilation finishes:
https://forum.kodi.tv/showthread.php?tid=329287

Not sure how well optimized the resulting binaries will be, as I didn't butcher the cmake build scripts to fine-tune the compiler flags, will check that with readelf after the compilation. In Kodi 17 it was easier to get the best code (optimized & using all (the proper) the HW accel) for these rather limited ARM SoCs:
https://www.linuxquestions.org/questions...175613852/

Besides, the configure script from 4.0.3-Leia-RC5.tar.gz looks to be broken:
https://www.linuxquestions.org/questions...ost5956641

I'll put this thread on resolved - thanks again!

[abga]

I thought the [100%] will never end, it took around 10 minutes. But then I finally got into the compilation end, a beautiful failure. I guess I need to wait for the RC2...

CMakeError.log:
https://pastebin.com/zKR9PXav
CMakeOutput.log:
https://pastebin.com/33Be0aN0
kodi-build.log (console) - last lines - last 5%:
https://pastebin.com/7GWrsZ3K

[Klojum]

@abga

Please don't post such large unreadable text blobs directly onto the forum. Use a pastebin website instead.

[abga]

@abga

Please don't post such large unreadable text blobs directly onto the forum. Use a pastebin website instead.

Sorry, my bad, corrected my post now.
This thread is already put on solved and maybe I should start a new one, but then what's the point? ...

[Klojum]

Thread has been unsolved.

[abga]

It looks like tinyXML related and I'm not sure I had the proper dependencies when I started the compilation. I'd be very thankful if someone more knowledgeable would translate into Linux the following term/nickname/slang/weirdo (don't know how to call it):
"libtinyxml-dev"
I'm asking this because I have  tinyxml v2.6.2 built and installed (Kodi 17 was happy with it) and there's also a tinyxml2 v7.0.1 available, which I can build if required.
Source - Section: 3. Install the required packages:
https://github.com/xbmc/xbmc/blob/master...E.Linux.md

[abga]

I had a parallel compilation running on Raspberry Pi 2B under SoftFloat, target being a Raspberry Pi Zero, that failed now at 97%, apparently trying to make use of the NEON SIMD instructions that are not available on the Pi Zero SoC, nor in the FFmpeg I built externally (that was the main reason for building it externally, fine-tuning). It must have been something automagically in the scripts determining that the armv7 SoC on the Pi 2B is NEON-able and thus breaking the compilation. I miss "the old days" when I had a configure script that I could tune. Not very versed with cmake and not sure I can provide some fine-tuning on the command line (nothing documented), instead of butchering the build scripts to my needs. Building Kodi 18 natively on Pi Zero will take ages.
Failure:

Code:

V=1 -DHAVE_LIBXSLT=1 -DHAS_AIRPLAY=1 -DFFMPEG_VER_SHA=\"4.0\" -I/usr/include/fribidi -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DHAS_GLES=2 -DHAS_EGL=1 -DHAVE_MMAL=1 -DHAS_MMAL=1 -DHAS_MYSQL=1 -DHAS_UPNP=1 -DHAS_DVD_DRIVE -DHAS_CDDA_RIPPER -DBIN_INSTALL_PATH=\"/usr/local/lib/kodi\" -DINSTALL_PATH=\"/usr/local/share/kodi\" -std=c++11 -o CMakeFiles/rendering_gles.dir/__/MatrixGL.neon.cpp.o -c /kit/kodi-slack-build/kodi/xbmc/rendering/MatrixGL.neon.cpp
/tmp/ccuaSSeU.s: Assembler messages:
/tmp/ccuaSSeU.s:27: Error: selected processor does not support `vldmia r1,{ q4-q7 }' in ARM mode
/tmp/ccuaSSeU.s:28: Error: selected processor does not support `vldmia r0,{ q8-q11 }' in ARM mode
/tmp/ccuaSSeU.s:29: Error: selected processor does not support `vmul.f32 q0,q8,d8[0]' in ARM mode
/tmp/ccuaSSeU.s:30: Error: selected processor does not support `vmul.f32 q1,q8,d10[0]' in ARM mode
/tmp/ccuaSSeU.s:31: Error: selected processor does not support `vmul.f32 q2,q8,d12[0]' in ARM mode
/tmp/ccuaSSeU.s:32: Error: selected processor does not support `vmul.f32 q3,q8,d14[0]' in ARM mode
/tmp/ccuaSSeU.s:33: Error: selected processor does not support `vmla.f32 q0,q9,d8[1]' in ARM mode
/tmp/ccuaSSeU.s:34: Error: selected processor does not support `vmla.f32 q1,q9,d10[1]' in ARM mode
/tmp/ccuaSSeU.s:35: Error: selected processor does not support `vmla.f32 q2,q9,d12[1]' in ARM mode
/tmp/ccuaSSeU.s:36: Error: selected processor does not support `vmla.f32 q3,q9,d14[1]' in ARM mode
/tmp/ccuaSSeU.s:37: Error: selected processor does not support `vmla.f32 q0,q10,d9[0]' in ARM mode
/tmp/ccuaSSeU.s:38: Error: selected processor does not support `vmla.f32 q1,q10,d11[0]' in ARM mode
/tmp/ccuaSSeU.s:39: Error: selected processor does not support `vmla.f32 q2,q10,d13[0]' in ARM mode
/tmp/ccuaSSeU.s:40: Error: selected processor does not support `vmla.f32 q3,q10,d15[0]' in ARM mode
/tmp/ccuaSSeU.s:41: Error: selected processor does not support `vmla.f32 q0,q11,d9[1]' in ARM mode
/tmp/ccuaSSeU.s:42: Error: selected processor does not support `vmla.f32 q1,q11,d11[1]' in ARM mode
/tmp/ccuaSSeU.s:43: Error: selected processor does not support `vmla.f32 q2,q11,d13[1]' in ARM mode
/tmp/ccuaSSeU.s:44: Error: selected processor does not support `vmla.f32 q3,q11,d15[1]' in ARM mode
/tmp/ccuaSSeU.s:45: Error: selected processor does not support `vstmia r0,{ q0-q3 }' in ARM mode
build/rendering/gles/CMakeFiles/rendering_gles.dir/build.make:134: recipe for target 'build/rendering/gles/CMakeFiles/rendering_gles.dir/__/MatrixGL.neon.cpp.o' failed
gmake[2]: *** [build/rendering/gles/CMakeFiles/rendering_gles.dir/__/MatrixGL.neon.cpp.o] Error 1
gmake[2]: Leaving directory '/kit/kodi-slack-build/kodi-build'
CMakeFiles/Makefile2:11531: recipe for target 'build/rendering/gles/CMakeFiles/rendering_gles.dir/all' failed
gmake[1]: *** [build/rendering/gles/CMakeFiles/rendering_gles.dir/all] Error 2
gmake[1]: *** Waiting for unfinished jobs....
[ 97%] Building CXX object build/interfaces/legacy/CMakeFiles/legacy_interface.dir/AddonUtils.cpp.o

[asavah]

Try adding -DWITH_CPU=arm1176jzf-s to cmake invocation
that should set the right flags for rpi 1/zero
See https://github.com/xbmc/xbmc/blob/master...etup.cmake

Edit: Hmm, I see you said you are building for softfloat (why??) , the above won't work because https://github.com/xbmc/xbmc/blob/master....cmake#L20
is explicitly setting mfloat-abi=hard.
It looks like you would need to patch that line to use the right flags for softfloat.

[abga]

Thank you for pointing me to that cmake file, it saved me a lot of detective work. Thanks also for  -DWITH_CPU=arm1176jzf-s , as mentioned I'm not versed with cmake, missed 20 years of its development, and was wondering if there is a way to investigate/list all these cmake parameters without actually parsing the cmake files, like in the fashion done for configure - ./configure --help
I'm compiling SoftFloat for Raspberry Pi1/0 because the distro I'm using, for historical&compatibility reasons, has only a SoftFloat port for armv5/armv6 (note that not all armv5/armv6 had a Hard FPU)
http://arm.slackware.com/introduction/
I was worried myself that SoftFloat would be slower than HardFloat, but I can state that a  Kodi 17 optimized compilation is faster (snappier) under Slackware ARM SF compared to the LibreELEC based on Debian HardFloat.

Inspecting https://github.com/xbmc/xbmc/blob/master...etup.cmake I can observe the compiler flags and I can tune them manually, not sure if they're the optimal ones and pretty sure they're not passed to the compiler.
 

Code:

  elseif(CPU STREQUAL arm1176jzf-s)
    set(ARCH arm)
    set(NEON False)
    set(NEON_FLAGS "-mcpu=arm1176jzf-s -mtune=arm1176jzf-s -mfloat-abi=hard -mfpu=vfp")

And:

Code:

# add Raspberry Pi 2 and 3 specific flags
if(CORE_PLATFORM_NAME_LC STREQUAL rbpi)
  if(CPU MATCHES "cortex-a7")
    set(NEON_FLAGS "-fPIC -mcpu=cortex-a7 -mfloat-abi=hard -mfpu=neon-vfpv4 -mvectorize-with-neon-quad")
  elseif(CPU MATCHES "cortex-a53")
    set(NEON_FLAGS "-fPIC -mcpu=cortex-a53 -mfloat-abi=hard -mfpu=neon-fp-armv8 -mvectorize-with-neon-quad")
  endif()
endif()

Some years ago, when I got my fist Pi boards, I spent some time (reading the compiler & ARM official docs) understanding the optimal compiler flags for the Raspberry Pi boards and came up with these:
Pi 1/0 - armv6  should be -mfloat-abi=hard for a HardFloat compiler enabled/compiled distribution

Code:

-march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=soft

Pi 2B - armv7

Code:

-march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mvectorize-with-neon-quad -mfloat-abi=hard

Pi 3 - armv8

Code:

-march=armv8-a+crc -mtune=cortex-a53 -mfpu=neon-fp-armv8 -mvectorize-with-neon-quad -mfloat-abi=hard

I mentioned I observed that the compiler flags from https://github.com/xbmc/xbmc/blob/master...etup.cmake were not passed to the compiler.
- under Slackware ARM -current (the development distribution - armv7 - HardFloat) on which I started my first native - Rpi 2B - compilation and opened this thread, in the build log I observed that the compiler flags used were:

Code:

-mtune=generic-armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -mtls-dialect=gnu -marm -march=armv7-a+fp

which are the default compiler flags! Confirmed that by using readelf on the resulting binaries.

On the parallel compilation Slackware ARM - SoftFloat on Rpi 2B -> target Raspberry Pi Zero, the one that failed because of the NEON instructions, I couldn't observe any CPU related compiler flags in the build log, other than the -D_ARMEL flag, but the readelf output for a compiled binary confirmed again that the default compiler flags were used:

Code:

Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "ARM10TDMI"
  Tag_CPU_arch: v5T
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-1

In both cases, as I'm used to, I tried to make sure the CFLAGS are set in the environment before I started the build, just in case a configure script might look after them.
First compilation, I used:

Code:

CFLAGS="-march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard"

Second one:

Code:

CFLAGS="-march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=soft"

Apparently these were ignored too.

I'll rebuild tinyXML and start again the first compilation. And for both compilations, I'll play with -DWITH_CPU= and maybe butcher the https://github.com/xbmc/xbmc/blob/master...etup.cmake file.

Thanks again for all the support, much appreciate it!

[asavah]

The flags in archsetup should be passed to the compiler.
Make sure that you DON'T pass -DWITH_ARCH= to cmake, otherwise -DWITH_CPU will get ignored.
Please note that kodi is mostly  c++, so you need to set CXXFLAGS !
The right way to do that for cmake project is like

bash:


-DCMAKE_C_FLAGS=

-DCMAKE_CXX_FLAGS=

-DCMAKE_C_LINK_FLAGS=

-DCMAKE_CXX_LINK_FLAGS=

-DCMAKE_EXE_LINKER_FLAGS=

[abga]

Thanks again for the cmake intro, slowly I'm getting used with it.
I started again the second compilation, the one that failed due to the NEON stuff on SoftFloat -> target Pi Zero
Went on and changed /kit/kodi-slack-build/kodi/cmake/scripts/linux/ArchSetup.cmake for the Pi Zero SoftFloat platform:

Code:

  elseif(CPU STREQUAL arm1176jzf-s)
    set(ARCH arm)
    set(NEON False)
    set(NEON_FLAGS "-march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=soft")

Used the following on console:

Code:

#not using java, only installed it for this compilation
export PATH="$PATH:/opt/java/bin"
# added these, just in case some configure scripts would look in the environment - not sure they're effective, see post #3 with the /opt/vc - include/ld
CFLAGS="-march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=soft"
CXXFLAGS="-march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=soft"
#configured the project:
cmake ../kodi -DCMAKE_INSTALL_PREFIX=/usr/local -DCMAKE_PREFIX_PATH=/opt/vc -DENABLE_INTERNAL_CROSSGUID=ON -DENABLE_INTERNAL_FLATBUFFERS=ON -DENABLE_INTERNAL_FMT=ON -DCORE_SYSTEM_NAME=linux -DCORE_PLATFORM_NAME=rbpi -DWITH_CPU=arm1176jzf-s -DCMAKE_C_FLAGS="-march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=soft" -DCMAKE_CXX_FLAGS="-march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=soft"
# didn't notice any NEON "Enabled" and the platform was picked up correctly: -- CPU: arm1176jzf-s, ARCH: arm
# started the compilation:
nohup cmake --build . -- VERBOSE=1 -j 4 2>&1 | tee kodi-build.log &

I could observe in the log that the proper CPU compiler flags were used, in some cases, well, most of the cases:

Code:

#here they are:
cd /kit/kodi-slack-build/kodi-build/build/texturepacker && /usr/bin/ccache /usr/bin/c++    -I/kit/kodi-slack-build/kodi/xbmc -I/kit/kodi-slack-build/kodi/tools/depends/native/Te
xturePacker/src -I/kit/kodi-slack-build/kodi/tools/depends/native/TexturePacker/src/decoder  -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=soft -std=c++11 -D_ARMEL -D
TARGET_RASPBERRY_PI -Wall -O3 -DNDEBUG -s   -D_LINUX -DTARGET_POSIX -DTARGET_LINUX -D_GNU_SOURCE -DHAVE_LINUX_MEMFD=1 -DHAVE_MKOSTEMP=1 -std=c++11 -o CMakeFiles/TexturePacker.di
r/src/md5.cpp.o -c /kit/kodi-slack-build/kodi/tools/depends/native/TexturePacker/src/md5.cpp
#...
#...
#...
# here they're not used:
/usr/bin/c++    -I/kit/kodi-slack-build/kodi-build/build/flatbuffers/src/flatbuffers/include -I/kit/kodi-slack-build/kodi-build/build/flatbuffers/src/flatbuffers/grpc  -std=c++0x -Wall -pedantic -Werror -Wextra -Werror=shadow -Wunused-result -Werror=unused-result -Wunused-parameter -Werror=unused-parameter -fsigned-char -O3 -DNDEBUG   -o CMakeFiles/flatc.dir/src/code_generators.cpp.o -c /kit/kodi-slack-build/kodi-build/build/flatbuffers/src/flatbuffers/src/code_generators.cpp

Hope it'll end up successfully. Now that I learned more about cmake, I'm starting to consider building FFmpeg internally/statically if the compiler flags are also passed to that dependency.

It'll take some time until the compilation finishes, I noticed it takes twice the time (around 4 hours) it used on Kodi17 (around 2 hours) on a Pi2B armv7 quad-core with 4 make jobs. Also, I observed that it goes over the 965MB available RAM on the native HardFloat armv7 compilation (the one reported in the beginning of this thread), got 180MB written in the swap at around [13%] in the build process, had to stop it and use only 3 make jobs.

I'll also start again the native Rpi 2B armv7 HardFloat compilation, need to recompile tinyXML and change the compiler flags in /kit/kodi-slack-build/kodi/cmake/scripts/linux/ArchSetup.cmake
It's late here, I'll leave the compilations to finish overnight and report tomorrow.

Again, thanks for all the help!

[abga]

Success! Both compilations, native Rpi 2B HardFloat - subject of this thread and the secondary SoftFloat compilation -> targeting Pi Zero.

Code:

gmake[2]: Leaving directory '/kit/kodi-slack-build/kodi-build'
[100%] Built target kodi
gmake[1]: Leaving directory '/kit/kodi-slack-build/kodi-build'
/usr/bin/cmake -E cmake_progress_start /kit/kodi-slack-build/kodi-build/CMakeFiles 0

For the first compilation, the native Rpi 2B, I had to recompile TinyXML, the package I had was somehow broken, and for both compilations I used the Kodi 18.1 RC1 - cloned the master, considering the changes interesting.
The reported problem has been solved, putting the thread on solved (again).


--- Extra - off topic - I might start a new thread because of this. If requested. I'm happy with the rock solid Kodi 17.4 ATM. ---

I only tested the build on the Raspberry Pi Zero and found it useless, as it's unable to play TV streams (both SD (MPEG2 (I own a license)) & Full HD (H264)) and even video files (again, both SD & HD (both H264 in this case)) without stuttering (both audio & video) while using the OMXPlayer and Pi Analogue Out. But that is something I also observed by testing the Kodi 18 LibreELEC Testbuilds during the last months.
- TV channels, both SD&HD, playback starts OK for a few seconds (2-5) and then it begins to stutter, both audio and video and it never recovers. Starting to play another channel goes through the same stages.
- video files, the same, for both SD & HD, it takes a little more time to load/start, compared to Kodi17.4, then it plays OK for a few seconds and the stuttering begins, again, never ends.
- spent some time investigating a little the system load with both bcmstat & htop and found out that the CPU stays usually at 50-60% (normal, the same in Kodi 17.4) and as I use the ondemand governor, it's also lowering the frequency every now and then. I set the governor on performance and it didn't help. Memory related, bcmstat reported plenty of GPU RAM available, even with 128MB. I tried also with 256MB GPU RAM without any positive results. It looks like the OMX engine is broken, buffering, not catching up.
- in case someone is interested, I created a debug log while playing a FullHD TV (H264) channel and a normal SD (MPEG2)  experiencing the audio&video stuttering:
https://pastebin.com/PhrSZsxr
(edited the log to clean up the information I considered private)

Another interesting thing I observed with this new compilation was the functionality of the VideoPlayer (MMAL). It looks like almost working fine on the Pi Zero. It does suffer from the "sound elasticity", that's slowing down and speeding up the sound, making it useless, but it doesn't kill the Pi Zero anymore, like it did in Kodi 17.4. This "sound elasticity" was only apparent on external (USB) sound adapters under Kodi 17.4 (available also in all the Kodi 17.4 based LibreELEC stable releases I tried), but now, in Kodi 18.1. RC1 it applies also on the Pi Analogue Out, weird. It also never recovers, although, with time it tends to level out a little. Must be something related to the clock source/sync on these Pi boards.

By trying to exclude the Linux distribution and very old kernel/firmware I use from causing these new found issues, I went on and upgraded the LibreELEC 8 image I had available with Kodi 18.1.RC1 from here:
https://forum.kodi.tv/showthread.php?tid...pid2816740
Did a manual upgrade, planted the tar file in /store/.upgrade/ and rebooted. After the reboot, everything worked well, apart from the remote (don't know what happened, my custom lircd.conf and Lircmap.xml were available and lircd was running), never mind. Tested this new Kodi 18.1.RC1 LibreELEC with the OMX Player and Pi Analogue Out on the same TV channels / video files and experienced the same stuttering, but it did recover after a few seconds. VideoPlayer under MMAL played me some "sound elasticity" and eventually recovered apparently for SD TV Channels, on FullHD Channels too, but it started to drop a lot of video frames and there was definitely a desync between the audio and the "slideshow-like" video.

----- End of Extra -----


Thanks again for all the support, it saved my a lot of detective work in finding out how to properly build for Raspberry with cmake.

[asavah]

Just a tip: for pi I prefer building Kodi from https://github.com/popcornmix/xbmc/tree/newclock5 ,
this branch contains some hefty pi specific optimizations and stuff not (yet) present in master,
like gpu-assisted HEVC decoding (not a pure hw decode, but gpu "lends a helping hand" to ffmpeg)  and a large etc.

There be some dragons tho.
You need to patch libbluray and ffmpeg with patches contained in
https://github.com/popcornmix/xbmc/tree/.../libbluray and https://github.com/popcornmix/xbmc/tree/...get/ffmpeg respectively,
for me newclock5 yields the best results on the pi 2/3/3b+

I haven't been using my pi1 for years so I can't tell anything about the stutters you are experiencing.