Hi Richard,
Thanks for the reply. When you said ....
> Yes, to ensure your native library dependencies are met in OSGi, it is best
> to explicitly load them in the proper order.
I think the crux of the problem is that for these particular libraries
there is no linear order that works.
You can throw them all on the LD_LIBRARY_PATH and the OS manages to
figure it out but you can't load them in a sequence.
Unfortunately these native libraries are from a database vendor so I
can't have them change them.
Regards,
Duncan
On Thu, Apr 28, 2011 at 3:07 PM, Richard S. Hall <he...@ungoverned.org> wrote:
> 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.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
>>
>
> ---------------------------------------------------------------------
> 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
