[blunden]

I'm attempting to test some modifications I made to a binary add-on but to do that, I need to build Kodi so that I can build and install the kodi-framework (which appears to have Kodi as a dependency). Since I was planning to test the add-on on Android, I first set everything up for cross-compiling for aarch64 with the Android NDK (using the official guide) and had no trouble building the dependencies.

However, since it seems like I need to build it for my host system as well in order to successfully build the add-on, ran ./configure again to change back to x86-64 Linux (Ubuntu 20.04). Most of the dependencies seem to build fine but it seems to error out when building mesa complaining that it it can't find the build.ninja file.

make -C mesa
make[2]: Entering directory '/home/blunden/kodi/tools/depends/target/mesa'
cd x86_64-linux-gnu-debug/build; /home/blunden/xbmc-depends/x86_64-linux-gnu-native/bin/ninja -v
ninja: error: loading 'build.ninja': No such file or directory
make[2]: *** [Makefile:83: x86_64-linux-gnu-debug/build/src/egl/libEGL.so] Error 1
make[2]: Leaving directory '/home/blunden/kodi/tools/depends/target/mesa'
make[1]: *** [Makefile:134: mesa] Error 2

I assumed that it might be caused by an earlier build failure/error futher up that was supposed to generate the file (the build.ninja files for other dependecies were seemingly generated by meson), but I don't see any. I've executed make a bunch of times until doesn't build anything else before erroring out with the message above. The Makefile lines don't really provide any obvious clues either. I've made sure that I have all the *-mesa-dev packages listed here.

EDIT: Running make distclean in ~/kodi/tools/depends/target/mesa and then rerunning make throws the following error:

Program python3 found: YES (/home/blunden/xbmc-depends/x86_64-linux-gnu-native/bin/python3)

meson.build:799:2: ERROR: Problem encountered: Python (3.x) mako module >= 0.8.0 required to build mesa

Installing the python3-mako module from Ubuntu's repo doesn't seem to make a difference though. I suppose the python3 binary built by as part of the dependencies might look for modules elsewhere. EDIT 2: Yes, installing the mako package only makes it available to system's default python3. Trying to import the mako module after running the compiled python3 binary above causes it to complain about the missing module while the system one works. EDIT 3: Removing the python3-mako package and installing mako using pip3 instead worked. I then had to install a bunch of other dependencies (running make distclean inside targets/mesa between each one for it to re-run the configure step).

EDIT 4: I'm still getting the same error about the XFILE namespace seen below. My understanding was that that would be solved by building and installing kodi-platform and p8-platform libs (which in turn required me to build kodi).

error: ‘XFILE’ is not a namespace-name

Any suggestions?

[blunden]

Is the XFILE namespace something legacy by any chance? I commented out the using namespace XFILE; line just to see what issues or compile errors it would cause but it actually ended up building and seemingly working fine. Unfortunately, it builds for Linux now instead of Android.

[wsnipex]

However, since it seems like I need to build it for my host system as well in order to successfully build the add-on, ran ./configure again to change back to x86-64 Linux (Ubuntu 20.04).

What makes you think that? You just have to follow https://github.com/xbmc/xbmc/blob/master...Android.md to build kodi.
then follow https://github.com/xbmc/xbmc/blob/master.../README.md for the addon.
Note the ADDONS_DEFINITION_DIR and ADDON_SRC_PREFIX variables that allow you to specify your modified repository file and addon source

[blunden]

However, since it seems like I need to build it for my host system as well in order to successfully build the add-on, ran ./configure again to change back to x86-64 Linux (Ubuntu 20.04).

What makes you think that? You just have to follow https://github.com/xbmc/xbmc/blob/master...Android.md to build kodi.
then follow https://github.com/xbmc/xbmc/blob/master.../README.md for the addon.
Note the ADDONS_DEFINITION_DIR and ADDON_SRC_PREFIX variables that allow you to specify your modified repository file and addon source

I thought that at the time because it seemed like the kodi-platform (saw someone mentioned that it might be where the XFILE namespace definition was declared, but it was unclear) and p8-platform dependencies might simply be needed for the build environment, not libraries to link with the add-on itself. Now it would appear to be the latter and needs to be built for the target architecture, which I've been unable to do.

I have followed the Android build instructions and can build Kodi for Android just fine. I can also build the binary addon in-tree from the source code in the official repo. That's the only method for building the addons in the Android build instructions but I also tried following the out-of-tree instructions for Linux as I figured that might work too. The problem I run into then is that I've been unable to get cmake to pick up the fact that I'm trying to cross-compile it so I end up with an x86_64 linux targetted addon. I tried pointing cmake to the Toolchain.cmake file in ~/android-tools/xbmc-depends too but it ends up complaining that the compiler is broken (although that compiler can seemingly compile Kodi).

Last night, I figured I might be able to trick the build system into building my modified code in-tree by forking the binary addon definition repo and modifying the definition to point to my code. After getting that to work and seeing it attempt to build my modified code, I'm basically stuck at the p8-platform dependency. How am I supposed to handle that when I can't manage to cross-compile it? I asked the same thing in another thread I found where you suggested essentially doing exactly this.

Basically, I can built the official code for the addon in-tree. This version doesn't depend on p8-platform. My version does depend on that library though so that's where I'm currently stuck since I've failed to successfully cross-compile it. I also know that my modified code compiles and works on Linux so the issue is cross-compiling p8-platform at this point.

[blunden]

Many plugins I've checked to see how they handle p8-platform seem to have removed that dependency within the last year or so it seems.

I suppose I can try adding it as an explicit dependency to the addon instead as a workaround like below.

https://github.com/kodi-pvr/pvr.hts/pull/440

~/kodi/tools/depends/target/p8-platform/ already exists though so I would expect it to find that when building in-tree.

Any hints?

EDIT: Adding it as an explicit dependency seems to have worked to make the build happy. It seems to have included debug symbols though so I'll have to look into making a release build of it.

[wsnipex]

yes, if you need p8-platform, the correct way to add it is adding https://github.com/AlwinEsch/pvr.hts/blo...atform.txt to your addon

[blunden]

yes, if you need p8-platform, the correct way to add it is adding https://github.com/AlwinEsch/pvr.hts/blo...atform.txt to your addon

Ok, I see. That must be fairly new, but it seems reasonable.

What's the best way to compile release versions of plugins btw.? I'm guessing that might be set at the configure step or possibly as a Makefile target? Searching for it seems to suggest a few different methods, with people reporting mixed results. Most of those threads are old though.

[wsnipex]

addons use the same CFLAGS as kodi, so if you configure kodi as release build, addons will be as well.

just configure depends with --disable-debug

[blunden]

addons use the same CFLAGS as kodi, so if you configure kodi as release build, addons will be as well.

just configure depends with --disable-debug

That worked, thanks!

[tutu]

I'm attempting to test some modifications I made to a binary add-on but to do that, I need to build Kodi so that I can build and install the kodi-framework (which appears to have Kodi as a dependency). Since I was planning to test the add-on on Android, I first set everything up for cross-compiling for aarch64 with the Android NDK (using the official guide) and had no trouble building the dependencies.

However, since it seems like I need to build it for my host system as well in order to successfully build the add-on, ran ./configure again to change back to x86-64 Linux (Ubuntu 20.04). Most of the dependencies seem to build fine but it seems to error out when building mesa complaining that it it can't find the build.ninja file.

make -C mesa
make[2]: Entering directory '/home/blunden/kodi/tools/depends/target/mesa'
cd x86_64-linux-gnu-debug/build; /home/blunden/xbmc-depends/x86_64-linux-gnu-native/bin/ninja -v
ninja: error: loading 'build.ninja': No such file or directory
make[2]: *** [Makefile:83: x86_64-linux-gnu-debug/build/src/egl/libEGL.so] Error 1
make[2]: Leaving directory '/home/blunden/kodi/tools/depends/target/mesa'
make[1]: *** [Makefile:134: mesa] Error 2

I assumed that it might be caused by an earlier build failure/error futher up that was supposed to generate the file (the build.ninja files for other dependecies were seemingly generated by meson), but I don't see any. I've executed make a bunch of times until doesn't build anything else before erroring out with the message above. The Makefile lines don't really provide any obvious clues either. I've made sure that I have all the *-mesa-dev packages listed here.

EDIT: Running make distclean in ~/kodi/tools/depends/target/mesa and then rerunning make throws the following error:

Program python3 found: YES (/home/blunden/xbmc-depends/x86_64-linux-gnu-native/bin/python3)

meson.build:799:2: ERROR: Problem encountered: Python (3.x) mako module >= 0.8.0 required to build mesa

Installing the python3-mako module from Ubuntu's repo doesn't seem to make a difference though. I suppose the python3 binary built by as part of the dependencies might look for modules elsewhere. EDIT 2: Yes, installing the mako package only makes it available to system's default python3. Trying to import the mako module after running the compiled python3 binary above causes it to complain about the missing module while the system one works. EDIT 3: Removing the python3-mako package and installing mako using pip3 instead worked. I then had to install a bunch of other dependencies (running make distclean inside targets/mesa between each one for it to re-run the configure step).

EDIT 4: I'm still getting the same error about the XFILE namespace seen below. My understanding was that that would be solved by building and installing kodi-platform and p8-platform libs (which in turn required me to build kodi).

error: ‘XFILE’ is not a namespace-name

Any suggestions?

I'm getting the same problem with "ninja: error: loading 'build.ninja': No such file or directory". But after make distclean in ~/kodi/tools/depends/target/mesa and make:

I get:

meson.build:370:4: ERROR: Problem encountered: EGL requires dri

Any ideas? UPDATE: i figured it out

[blunden]

addons use the same CFLAGS as kodi, so if you configure kodi as release build, addons will be as well.

just configure depends with --disable-debug

It's a bit weird that this no longer seems to work for me when building for Kodi 20, at least if you trust the output of the 'file' command, even though the build output seems to suggest it should be a release build. The resulting binary is much smaller than the debug one I built for Kodi 19 in 2021 so the number of debug symbols is presumably much lower at the very least.

I even compared the configure command I used to the one in my terminal scrollback history that worked last time.

./configure --with-tarballs=$HOME/android-tools/xbmc-tarballs --host=aarch64-linux-android --with-sdk-path=$HOME/android-tools/android-sdk-linux --with-ndk-path=$HOME/android-tools/android-ndk-r21e --prefix=$HOME/android-tools/xbmc-depends --disable-debug

Btw. is p8-platform being deprecated? I noticed that the Kodi fork of it is missing a fix for building in C++17 mode, which prevents it from building in Kodi 20. I could submit a pull request with the missing commit (applies cleanly cherry-picked on top of the current master branch of the kodi p8-platform fork) if you want?

[izprtxqkft]

for those of us who werent around 2 years ago when this thread was active, could you accurately describe what is not working "that worked last time"?

[blunden]

for those of us who werent around 2 years ago when this thread was active, could you accurately describe what is not working "that worked last time"?

I figured it could be understood from the quoted post, but I guess it was unclear.

The thing that I thought wasn't working anymore was the "--disable-debug" flag since the binaries still include debug information according to the file command. It's still much smaller than one with full debug symbols so it's probably fine. Still doesn't match the official builds of the same plugin so clearly we are building with different flags or something. Basically, I just found this odd.

[izprtxqkft]

i see now, thanks

i never investigated my compilations for linux so i didnt know there were still debug sections in the resulting binaries...