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.

On 29/07/14 12:05, 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. This probably means patching upstream sources.

Debian patches the default search path so that System.loadLibrary() searches /usr/lib/jni for DSOs with native code. This means that classes which call System.loadLibrary() just work, assuming that the Debian package installs its DSOs into /usr/lib/jni.

Can we do something similar in Fedora? We probably want /usr/lib/jni and /usr/lib64/jni, for consistency with the rest of the system.

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.

Ideally we'd want to have this discussion with Java upstream.

Depending on a Fedora-local patch to the search path means that if people build their own OpenJDK or install Oracle Java, their programs will stop working. So, we must not do that.

If a symlink at /usr/java/packages/lib/amd64 to wherever is allowable, and I see no reason why it should not be, then we don't need to patch OpenJDK. We could make /usr/java/packages/lib/amd64 a real directory, and populate it with symlinks to the packages or make it just a symlink to /usr/lib64/jni ; again, I don't think it matters.

Andrew.