We are accessing native libraries from Java. This works outside of OSGi and in OSGi on Windows but not on Linux probably because the dll and so linking behave differently.
I have tried the following experiments: 1) add libraries to LD_LIBRARY_PATH and System.loadLibrary() only the top level JNI library. The dependent libraries are all linked implicitly and the unit tests run. 2) add libraries to LD_LIBRARY_PATH and explicitly load them all in reverse dependency order. The libraries link but the tests fail at run time with inscrutable errors from the C code. 3) add all libraries to Bundle-NativeCode entry . Explicitly load only the JNI library. Fails to link with the other libraries. [This would have been my preferred approach] 4) add all libraries to Bundle-NativeCode entry and explicitly load them all in reverse dependency order. The libraries link but the tests fail at run time with inscrutable errors from the C code. 5) tried all of the above with Felix and Equinox. So it appears that OSGi requires that I explicitly use System.loadLibrary for all the libraries. However, the C libraries that I am trying to use are not able to withstand this on Linux (but they do on Windows). These are native libraries from a major vendor and there is little chance of them patching them for me. If the libraries can be loaded from LD_LIBRARY_PATH then you would think that OSGi should also work. But OSGi appears to require that I explicitly load all libraries myself which resolves the dependencies in a subtly different way to how the LD_LIBRARY_PATH approach behaves. So possible outcomes are: 1) if the libraries can be loaded from LD_LIBRARY_PATH then OSGi should reasonably be expected to load them as well. 2) OSGi works like this for a reason and native libraries need to be redesigned so they can withstand being loaded explicitly. I am considering writing a bundle that iterates through all the resolved bundles (at start up) and copy their .so files into a common location that I will put on the java.library.path. I believe this would work but feels like a hack. Any comments or suggestions would be most appreciated. Cheers, Duncan --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
