How to use OSGi fragments to contribute platform-dependent native code with the same filename?

Question

I am using the JNotify project to listen to file system events. This depends on one native library per OS:processor architecture. For example, there's one library for Windows x86, one library for x86-64 etc.

Monolithic bundle

Originally, I had one bundle that contained both the JNotify Java classes and the native code. The native code were declared in Bundle-NativeCode as follows:

(I've formatted these in the bnd style for better readibility... obviously the actual MANIFEST.MF files are properly formed).

Bundle-NativeCode: jnotify_64bit.dll;osname=Win32;osname="Windows NT (unknown)";osname = WindowsXP;osname = Windows2000;osname = Windows2003;osname = WindowsVista;osname = Windows7;osname = WindowsServer2008;osname= Windows8;osname = WindowsServer2012;processor = x86-64,\
 jnotify.dll;osname=Win32;osname="Windows NT (unknown)";osname = WindowsXP;osname = Windows2000;osname = Windows2003;osname = WindowsVista;osname = Windows7;osname = WindowsServer2008;osname = Windows8;osname = WindowsServer2012;processor = x86,\
 libjnotify.so;osname = Linux;processor = x86,\
 libjnotify64.so;osname = Linux;processor = x86-64,\
 libjnotify.dylib;osname = Mac OSX;processor = x86;processor = x86-64,\
 *

This worked well.

Move to fragments

I figured it would be 'nice' if I moved the libraries into separate fragment bundles so that I could just contribute the fragments for the architecture I am interested in. Taking the example of Linux, I split them into two bundles:

Linux 32 bit

Include-Resource: lib/libjnotify.so
Bundle-NativeCode: libjnotify.so;osname = Linux;processor = x86,\
    *
Fragment-Host: net.contentobjects.jnotify
Bundle-Version: 0.94.0

Linux 64 bit

Include-Resource: lib/libjnotify.so
Bundle-NativeCode: libjnotify.so;osname = Linux;processor = x86-64,\
    *
Fragment-Host: net.contentobjects.jnotify
Bundle-Version: 0.94.0

Note that these bundles are built from different source. Although the libjnotify.so filename is the same they are different files in different Eclipse projects. They have to be the same to work with JNotify.

Note that the same filename is contributed to the host bundle. In this case the filename is libjnotify.so.

If I run these on my 64 bit machine with the 64 bit bundle being loaded before the 32 bit one, it works.

However, if the 32 bit bundle gets loaded first, I get:

Couldn't initialise JNotify: java.lang.UnsatisfiedLinkError: /blah/generated/fw/bundle46/version0.0/net.contentobjects.jnotify.linux.x86-0.94.0.jar-lib/0/libjnotify.so: /blah/generated/fw/bundle46/version0.0/net.contentobjects.jnotify.linux.x86-0.94.0.jar-lib/0/libjnotify.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch) (JnotifyFileSystemObserver.java:53, thread platformExecutor)

Clearly the 32 bit library is being loaded. But why? My Bundle-NativeCode defines the host must be a 32 bit Linux machine to use the 32 bit bundle's version. I thought if that clause doesn't match, the library is ignored?

Stuff I've tried

• Removing the optional wildcard... this just means the bundles don't resolve

Answer 1

Since your fragment occupy the same resource namespace only one .so file can be accessed. You can deploy only one fragment, or you could try putting them in different directories:

 Fragment 32-bit:
 Include-Resource: x32/libjnotify.so=lib/libjnotify.so

 Fragment 64-bit:
 Include-Resource: x64/libjnotify.so=lib/libjnotify.so

I also think you need to put the Bundle-NativeCode header in the host bundle and refer to the proper directories since I am I think this header is not merged in the host.

Answer 2

Check what version of Eclipse/OSGi container are you running. I suspect you find that the container you are launching has os set to a 32 bit system.

Answer 3

If you don't mind being restricted to Equinox you can use one-fragment-per-platform solution with Eclipse-PlatformFilter. In this case, only one fragment with native code can be resolved and installed at any time thus avoiding namespace conflict.