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
