[fedora-java] /usr/lib/jni support in Fedora

[David M. Lloyd]

On 07/29/2014 06:05 AM, Florian Weimer wrote:
> As far as I can tell, currently, System.loadLibrary() is mostly unusable
> for Java libraries because they cannot influence the library search
> path.  If you want to transparently load a DSO, you need to use
> System.load() and hard-code the path.

Here's a bit more information on native library loading which might be 
useful.

When loading a native library, the first thing that happens is that the 
system will identify the class loader of the class with the method that 
actually calls loadLibrary().  Then it will ask this class loader to map 
the name passed into loadLibrary (e.g. "tcnative") to a properly named 
absolute path on the filesystem (e.g. "/usr/local/lib/libtcnative.so"). 
  The proper naming is usually done by a class loader by calling 
System.mapLibraryName() which translates e.g. "tcnative" to 
"libtcnative.so" (on Linux, and different mappings in different OSes).

So if you're dealing with an environment where the class loader is 
controlled, for example an application server, mostly the "right path" 
will be chosen - WildFly for example will look for native libraries 
along side the modules which load them.

However if this is a run-of-the-mill Java JAR trying to load some native 
stuff, the class loader will typically return "null" indicating that it 
has no mapping for the native library.  In this case, the 
java.library.path system property is consulted and the paths contained 
therein are searched, one by one, using the standard name mapping scheme 
described above.

Only if no matches are found using this mechanism will it default to the 
compiled-in paths AFAIK.

Once the library is found, the normal ld.so linkage rules apply since 
AFAIK it's a plain dlopen().

> The upstream default search path starts with
> "/usr/java/packages/lib/amd64" (and variants for other architectures),
> but this isn't mentioned in the Fedora guidelines.  I'm also not sure if
> we want to use this file system location because it doesn't look
> particularly FHS-compliant.  But the proprietary JDKs could install a
> symlink there so that /usr/lib{,64}/jni is searched as well.

Changing this default path seems like a sensible approach to me, FWIW.

-- 
- DML