Hi Duncan,
Bundle-NativeCode will probably be your best bet: it allows you to leave the
selection of the library up to the framework, and you can quite easily reload
your library by updating the bundle.
You will have to load your libraries with System.loadLibrary, OSGi only takes
care of selecting the right library for you. Note that different os's can have
different ways of naming their libraries: for instance, you can use
loadLibrary("library") to load 'library.dll' on windows, but on Linux it will
be 'liblibrary.so' (iirc). This naming convention might be the cause of your
problem.
If loading the libraries using loadLibrary form outside OSGi, there is no
reason this shouldn't work in OSGi.
Angelo
On Apr 28, 2011, at 8:08 PM, duncan wrote:
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
