Hello! I am sbout to release my binding, which uses substantial amount of native code (4 libraries):
libopensdg_jni
libopensdg
libprotobuf-c
libsodium
(1) and (2) are my code. (3) and (4) are 3rd party. (3) perhaps comes with even more dependencies.
I already know that OSGi does a very good job of managing embedded .so’s. The only question is: should i bundle in the whole 3rd party chain? Currently i bundle in only (1),. (2) comes as a .deb, because installing it would pull the rest in.
Are there any requirements regarding that for binding contribution?
Technically it’s possible to rewrite the whole thing in Java, but i am not feeling up to do this. I would like to move on instead.
I am not sure of the actual structure of remaining dependencies. Automatic loading of native libs is possible via combination of Bundle-NativeCode and System.loadlibrary calls.
Possible values of native code headers (os/processor) values are available in OSGi headers: https://www.osgi.org/developer/specifications/reference/
Advantage on bundling the native libraries is automated management of these by framework. Normally if you rely on external java.library.path it can be modified without your application knowledge. If your native deps are stable and do not change often then you can rely on user managed process, otherwise rely on native dependencies bundled as osgi modules.
(1) depends on (2) being a JNI stub, (2) depends on the rest from this list. I can link (1) and (2) together, since both are my code, but the rest is 3rd party. And it feels too cumbersome to include so many binaries.
This concerns only Linux. On Windows the problem doesn’t exist since it’s possible to link a .lib into a .dll.
Of course i know about Bundle-NativeCode; and this is how i include the JNI stub
Well… to give you idea of people tried to do and showed during EclipseCon 2018… I’ve seen presentation where whole nodejs executable and node-red been packaged, looked up and unpacked at runtime, everything using native code headers. It was tens if not hundreds of megs. Eclipse project uses bundle fragments to carry on native libraries so you can follow this path too.
Does static linking reduces amount of libs which needs to be looked up? Maybe that’s the option to get just one (or two) libs to be loaded?
On Linux it’s impossible to link .a into .so due to PIC vs non-PIC code differences. In order to do a static linking i would need to build everything from scratch on my own as static libs with PIC code. To tell the truth i’d like to avoid doing that.
So currently i am thinking about packaging libopensdg as .deb package and tell in README.md of my binding the it is required to install the library on the system. Then dpkg will take care about the rest of dependencies. When packaging Openhabian you would need to add this .deb as a dependency to openhab-addons package. For me it’s the simplest way to go. Is it OK for binding submission ?
