I guess that in your case the only thing you can do is to extract the
libraries yourself i.e., on Bundle start-up you would extract all
libraries via BundleContext.getEntry() into a tmp dir that you create
via BundleContext.getDataFile() and then load your top-level dll via a
System.load() call directly.
That should work alas, it doesn't get you any help from OSGi.
regards,
Karl
On Fri, Apr 29, 2011 at 12:21 AM, duncan <duncan.ch...@gmail.com> wrote:
> 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
>
>
--
Karl Pauls
karlpa...@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
