felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Bundle-NativeCode question.
Date Thu, 28 Apr 2011 21:07:40 GMT
On 4/28/11 16:56, duncan wrote:
> 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.

Yes, to ensure your native library dependencies are met in OSGi, it is 
best to explicitly load them in the proper order.

> 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.

I'm not sure why this would be problematic on LInux. Seems odd. Seems 
like it should work.

You could try a little experiment:

   1. First run your example according to approach (4) below to generate
      your Felix bundle cache. Stop the framework and keep the cache.
   2. Then modify your bundle to only load your JNI library a la
      approach (3) below.
   3. Copy the modified bundle directly into the bundle cache. If your
      bundle where installed as ID 4, for example, then you overwrite
      felix-cache/bundle4/version0.0/bundle.jar.
   4. Restart the framework and start your bundle if it doesn't
      automatically get restarted.

Not sure if this will make a difference, but it basically ensures that 
all native libraries are extracted in the same disk directory before you 
try to load them.

-> richard

> Best Wishes,
>
> Duncan
>
>
>
>
> On Thu, Apr 28, 2011 at 12:29 PM, Angelo van der Sijpt
> <angelo.vandersijpt@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-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
>>
>>
> ---------------------------------------------------------------------
> 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