felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angelo van der Sijpt <angelo.vandersi...@luminis.eu>
Subject Re: Bundle-NativeCode question.
Date Thu, 28 Apr 2011 18:29:22 GMT
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-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message