Load dependent .so from other shared library via JNI

Question

I want to call some function of liba.so from other libb.so. libb.so is dynamic so library that implement native method which i have loaded using System.loadLibrary("b") inside JNI. first i have set complete path for both of .so inside jni using java.library.path but when i run my java programs , while loading shared library libb.so, it gives below error:

Exception in thread "main" java.lang.UnsatisfiedLinkError: x/y/z/libb.so: liba.so: cannot open shared object file: No such file or directory.
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1857)
        at java.lang.Runtime.loadLibrary0(Runtime.java:870)
        at java.lang.System.loadLibrary(System.java:1122)

first i have linked shared library liba.so with other shared library libb.so during compilation using

g++ -shared -o libb.so -fPIC b.cc -L/x/y/z -la

(say complete path of liba.so is /x/y/z)
In JNI, i have set java.library.path pragmatically that contains complete path of liba.so, libb.so and then i used to load JNI native library libb.so as

(say complete path of libb.so is a/b/c and complete path of liba.so is x/y/z.)

String libpath = "x/y/z" + "a/b/c";
System.setProperty( "java.library.path", libpath);
    try {
        Field fieldSysPath = ClassLoader.class.getDeclaredField("sys_paths");
        fieldSysPath.setAccessible( true );
        fieldSysPath.set( null, null );
       }
    catch (Exception e)
      {
        System.out.println(e);
      }

// here i am able to print/fetch correct java.library.path. (path of both shared library saved correctly into java.library.path)

static {
    System.loadLibrary("b");
}

when my java programs load this dynamic library of static block , it gives below error:

Exception in thread "main" java.lang.UnsatisfiedLinkError: x/y/z/liba.so: libb.so: cannot open shared object file: No such file or directory.

Note: When i set path of liba.so in LD_LIBRARY_PATH, this work fine without any error. but i don't want to set LD_LIBRARY_PATH in SHELL. just i want to set java.library.path or LD_LIBRARY_PATH in program itself.

Thanks in Advance!

Take a look here: http://jnicookbook.owsiak.org/recipe-No-023/ — Oo.oO, Jan 25 '19 at 21:54
@Oo.oO, when i set path of liba.so in LD_LIBRARY_PATH, then its works. but when i try to set depended library( liba.so) path in java.library.path through program, it gives error. — Law Kumar, Jan 26 '19 at 07:22
it will not work with java.library.path. once inside liba.so you depend on system. — Oo.oO, Jan 27 '19 at 07:33
@Oo.oO, even when i set path of liba.so in LD_LIBRARY_PATH inside program, it won't work. i think you can't change the LD_LIBRARY_PATH setting for a running process inside program once its already started. I searched various discussion, I am not able to find a way to overcome above error without setting LD_LIBRARY_PATH in SHELL before program starts. — Law Kumar, Jan 27 '19 at 08:44
take a look here: http://jnicookbook.owsiak.org/recipe-No-018 — Oo.oO, Jan 27 '19 at 10:58
yes, that's what i have done, but point is you have to always set path of other library that you open in native library in LD_LIBRARY_PATH. This other dependent library path (liba.so ) can't be set at runtime once JVM has started. — Law Kumar, Jan 28 '19 at 06:16
you can also use -rpath while building liba.so and pointing to libb.so. at some point, somehow, you have to tell liba.so how to find libb.so :( — Oo.oO, Jan 28 '19 at 08:06

score 2 · Answer 1 · answered Nov 13 '19 at 17:13

Assuming you control the location of the shared objects liba.so and libb.so, compile your libb.so shared object with an embedded RPATH set so that it can locate liba.so.

If the two shared objects are located in the shame directory, this would work:

g++ -shared -o libb.so -fPIC b.cc -L/x/y/z -la -Wl,-rpath,'$ORIGIN/.'

($ORIGIN by itself would work, but I like to use $ORIGIN/. to clearly show the result is a directory. If you have the common bin and lib directory tree, always using $ORIGIN/../lib for both executables and shared object is also IMO a good idea.)

The -Wl,-rpath,'$ORIGIN/. will set an RPATH in the libb.so shared object so that the runtime linker searches the same directory libb.so is located in for liba.so.

score 1 · Answer 2 · answered Nov 12 '19 at 18:49

Loading a dependent library from a native library is a purely OS action so it's outside of Java control. Unfortunately, you cannot fix this issue with Java-provided instruments.

As you noted, in Linux library search path can be set by the LD_LIBRARY_PATH environment variable, but it's not possible to modify the environment variable of the already running JVM process (see here with a suggestion for a hack using gdb not really usable for the non-debug case).

The issue you described is filed as a JDK bug for Windows https://bugs.openjdk.java.net/browse/JDK-8213772 with a comment there is really nothing we can do.

However, there should be a simple solution for your case:

Load the dependent library liba.so explicitly prior to loading libb.so:

    static {
        System.loadLibrary("a");
        System.loadLibrary("b");
    }

In the case of multiple dependent libraries and deeper dependency hierarchy levels, load all the dependent libraries manually one by one in reverse order.

Load dependent .so from other shared library via JNI

2 Answers2

Linked