[Hoshpak]

I am currently looking into a relatively young distribution called Void Linux (http://www.voidlinux.eu/) which I intend to use to run kodi on. Since that computer I want to use for that uses a several year old Atom processor, I can only use the i686 version of Void for that. There's no working version of kodi for that architecture in the Void repository yet so I looked into what would be necessary to make kodi work there. One issue (segfault in TexturePacker) was relatively easily solved by disabling static builds of that component.

Now I'm able to build a binary package of kodi however it fails to start when one of the kodi scripts (kodi or kodi-standalone) is called since it fails to find the global userdata directory. I was able to track the issue down to the fact that the configure script is called with --libdir=/usr/lib32. This is technically correct since the libdir is named like that on the i686 architecture in Void. When the resulting binary which resides in /usr/lib32/kodi/kodi.bin is started, it looks for the userdata in /usr/lib/kodi/userdata, fails to find it (it would be in /usr/share/kodi/userdata) and exits.

If I execute the configure script with --libdir=/usr/lib which is possible since that is a symlink to /usr/lib32 but not a proper solution for the issue in my opinion, the resulting binary also looks in /usr/lib/kodi/userdata, fails to find it there, then continues to look in /usr/share/kodi/userdata, finds it and starts up just fine. I looked into the code in xbmc/Util.cpp and xbmc/Application.cpp but could not determine myself what causes the issue.

Of course manually setting the KODI_HOME environment variable and exporting it also leads to the binary finding the proper userdata directory but that's another workaround. If possible, I would rather get to the bottom of the issue and find a fix that leads to the binary finding the correct directory even if it was not compiled with --libdir=/usr/lib.

[wsnipex]

also set --datarootdir=/usr/share/kodi (adjust to your prefix)

[Hoshpak]

Thanks. I tried that but unfortunately it doesn't seem to change anything regarding this issue. After reconfiguring and -compiling kodi with that option:

Code:

[pid  6140] readlink("/proc/6140/exe", "/usr/lib/kodi/kodi.bin", 4096) = 22
[pid  6140] stat64("/usr/lib/kodi/userdata", 0xbfdef2ac) = -1 ENOENT (No such file or directory)
[pid  6140] readlink("/proc/6140/exe", "/usr/lib/kodi/kodi.bin", 4096) = 22
[pid  6140] stat64("/usr/lib/kodi/userdata", 0xbfdef2ac) = -1 ENOENT (No such file or directory)
[pid  6140] write(2, "Unable to find path to Kodi data"..., 40Unable to find path to Kodi data files!

In /usr/bin/kodi it is set as follows:

Code:

prefix="/usr"
exec_prefix="${prefix}"
datarootdir="/usr/share/kodi"
LIBDIR="/usr/lib32"
CRASHLOG_DIR=${CRASHLOG_DIR:-$HOME}
USERDATA_DIR="${HOME}/.${bin_name}"

[wsnipex]

please pastebin the config.log and the kodi log, if one was created

[Hoshpak]

I uploaded the config.log here:

http://pastebin.com/yyPVVFCc

A kodi.log is not created. I tried raising the loglevel but I guess the startup fails too early to produce a log.

[asavah]

Hmm there something fishy with your OS or setup,
I tend to make weird kodi builds with lots of dependencies homed at /opt/builds/kodi linked with RPATH in LDFLAGS,
and everything works properly

Code:

readlink("/proc/10830/exe", "/opt/builds/kodi/lib/kodi/kodi.b"..., 4096) = 34
stat("/opt/builds/kodi/lib/kodi/userdata", 0x7ffd16630620) = -1 ENOENT (No such file or directory)
readlink("/proc/10830/exe", "/opt/builds/kodi/lib/kodi/kodi.b"..., 4096) = 34
stat("/opt/builds/kodi/share/kodi/userdata", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0

I build with --prefix= changed only.
in your case --prefix=/usr --libdir=/usr/lib32 should suffice.

The answer may be in https://github.com/voidlinux/void-packag...i/template
I don't know what the hell those ppl did, but they ship source files which should be generated by swig at bootstrap time from their own repo...

You'd better ask your distro people or build kodi straight from git sources as opposed to some weird templates.

[wsnipex]

indeed, the packaging is questionable...
try with vanilla kodi.

[fritsch]

Funny how people ruin software cause they don't like the JAVA dependencies ...

[Hoshpak]

The only thing that could be seen as "fishy" from my point of view is the symlink at /usr/lib32 (it points to /usr/lib, not the other way around, I got that wrong in the first post) and that it is passed as libdir specifically on the i686 platform. I can only assume that there's a good reason for it but don't know enough about the build systems to know why it might be necessary. I looked at the prebuilt files and while I understand that upstream developers might not like the fact how it is done, the code in these files seems to relate to the issue discussed here in no way.

I wanted to test the theory that it's an issue with the environment so set up a VM with a fresh Debian testing VM, downloaded the vanilla kodi sources, installed all dependencies and created a symlink from /usr/lib64 to /usr/lib/x86_64-linux-gnu (it was a amd64 based system in this case) and configured kodi with --prefix=/usr --libdir=/usr/lib64. As I expected, the resulting binary is unable to find the userdata directory and fails to start.

My conclusion from this would be that it's not an error in the environment/distribution but a general issue which occurs if the libdir is specified, is in /usr but is not "lib". During configuration - only if libdir is specified - the variable APP_LIB_DIR is created and seems to be written into the kodi.bin binary. At least I can find /usr/lib64/kodi in the binary when I'm analyzing it with "strings". Now the code that determines the data dir from the environment seems to fail to detect the proper directory in this (admittedly) special case. I would appreciate it if someone familiar with the C++ code responsible for the directory detection could look deeper into this. Otherwise I will put it on my TODO list and get back to it as an academic exercise for myself once I've got more time for this than I have now.

As for the Void package, one of the developers pointed out that it might be a suitable workaround to just remove --libdir from the variable that defines the configure parameters. I submitted a pull request to do exactly that in the template file. If it is accepted, the package will finally work again for Void i686.