Hi Angelo,
Thanks for your response. I understand what you wrote but I think I am
at the point where I have convinced myself that using
System.loadLibrary() within OSGi can be subtly different to using it
outside. The behavior might be equivalent if you have a single library
but in my situation we have multiple dependent libraries.
Outside of OSGi you just call System.loadLibrary() on the topmost one
and leave it to the OS to resolve the dependencies (from
LD_LIBRARY_PATH). To find libraries in bundles in OSGi you apparently
have to call System.loadLibrary() for each of your libraries.
On Windows this amounts to the same thing. But on Linux the results
can be different. So you can have a suite of dependent libraries that
will link and run fine if you get them from LD_LIBRARY_PATH. But if
you try and load each one separately from bundle(s) there are
situations where they either won't resolve or will fail at run time.
Best Wishes,
Duncan
On Thu, Apr 28, 2011 at 12:29 PM, Angelo van der Sijpt
<angelo.vandersi...@luminis.eu> wrote:
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
