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