JNA bindings test fails on Build Server

[e1528532]

Looks like the JNA bindings test fails on the build server because the Elektra library cannot be loaded. I guess the build server has no actual elektra installation, so it doesn't find the dynamic library. I have to check if there is a possibility to point it to the right path in such environment. I guess its better to point it to load dynamic libraries from the build directory anyway and not rely on a system installation. If required we can exclude the test for now.

[markus2330]

Please let the test pass if no Elektra installation was found. (You can do this even within Java I suppose?) Other external tests deactivate themselves, too.

[markus2330]

Thank you for putting the reference here. Please always try to add a link to the build server or ideally even copy&past the error. When talking about the build server, we usually mean https://build.libelektra.org/, and not travis.

[e1528532]

So I've tried to make the tests work on macOS when no elektra is installed, but without success yet (see #1360 ). Tried updating jna version, setting some flags for dlopen in jna, setting LD_LIBRARY_PATH/DYLD_LIBRARY_PATH both in the shell and in the pom file for surefire (the maven test plugin), and a bunch of other things i've already forgotten about.

I guess the issue boils down due to macOS 10.11 and onwards not allowing to load shared libraries from other locations than the default one for restricted applications.

Spawning children processes of processes restricted by System Integrity Protection, such as by launching a helper process in a bundle with NSTask or calling the exec(2) command, resets the Mach special ports of that child process. Any dynamic linker (dyld) environment variables, such as DYLD_LIBRARY_PATH, are purged when launching protected processes.

The problem is that java is usually marked as restricted (as a part of macOS's System Integrity Protection), and maven is java based, so this seems to apply to maven too. Therefore it doesn't pass the adjusted dynamic library path for the test, thus it fails. And thats also the reason why it works on my arch where i tried it too, and on the old macOS 10.10 on travis.

You could now argue why it loads libelektra.dylib successfully. To my understanding, thats because it is loaded by JNA where you can customize the location with the jna.library.path argument. But then when using KDB, it fails, as using KDB seems to imply elektra loading the libelektra-resolver.so shared library. But this happens outside of java/jna, so it looks it up in the DYLD_LIBRARY_PATH or uses the RPATH mechanism (not totally sure about that yet), and as this does only search in the system locations, it fails unless elektra is installed.

I could check if its possible to exclude the KDB tests if the platform is macOS > 10.11 for a workaround. Then at least the travis builds should suceed again. Using KDB when having elektra installed works fine on macOS so its not that critical.

The usual suggestion is that ideally you avoid having to set the LD path manually. Maybe its related to #1275 somehow? Ah and a last thing that might be relevant, shouldn't libelektra reference the libelektra-resolver.so if it is using it at some point?

% otool -L ~/git/libelektra/build/lib/libelektra.4.dylib
/Users/admin/git/libelektra/build/lib/libelektra.4.dylib:
        @rpath/libelektra.4.dylib (compatibility version 4.0.0, current version 0.8.19)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.0.0)

[markus2330]

I could check if its possible to exclude the KDB tests if the platform is macOS > 10.11 for a workaround. Then at least the travis builds should suceed again. Using KDB when having elektra installed works fine on macOS so its not that critical.

Sounds fine!

Maybe its related to #1275 somehow?

#1275 is only about installed Elektra.