degratnik degratnik - 5 months ago 27
Java Question

System.loadLibrary does not work. UnsatisfiedLinkError for the second lib in chain

I have java program Client.class that uses cpp shared library libclient.so via JNI.
libclient.so is built as shared and uses cpp shared library libhttp.so.

libclient.so and libhttp.so are placed in folder

/home/client/lib64


Client.class is placed in
/home/client/bin


Client can load library with


  1. System.load and environment variable LD_LIBRARY_PATH

  2. System.loadLibrary and -Djava.library.path



The first way works fine.

export LD_LIBRARY_PATH = /home/client/lib64



java -classpath ./bin Client

The secon way fails.

java -classpath ./bin -Djava.library.path=./../lib64 Client



java.lang.UnsatisfiedLinkError: /home/client/lib64/libclient.so: libhttp.so: cannot open shared object file: No such file or directory


When I put libhttp.so into /usr/lib64 the second way works fine.

Why libclient.so is looking for libhttp.so in /usr/lib64 if I use System.loadLibrary?
How can I fix it without coping libhttp.so into /usr/lib64?


My loading code:

//Try load from -Djava.library.path
boolean found = false;
String lib = "client";
try {
System.loadLibrary(lib);
found = true;
} catch (UnsatisfiedLinkError e) {
e.printStackTrace();
}
//Try load from LD_LIBRARY_PATH
if (!found) {
lib = "libclient.so";
String ld_lib_path = System.getenv("LD_LIBRARY_PATH");
String[] paths = ld_lib_path.split(":");
for(int i=0; i<paths.length; i++) {
String p = paths[i];
File x = new File(p, lib);
if (x.exists()) {
System.load(x.getAbsolutePath());
found = true;
break;
}
}
}


Additional information.

If I test libclient.so with ldd then I see: libhttp.so => not found
If I set export LD_LIBRARY_PATH = /home/client/lib64 then I see: libhttp.so => /home/client/lib64/libhttp.so

Answer

The reason for this is that libclient.so is loaded from your JVM, which looks in java.library.path. However, when libclient.so tries to load libhttp.so, it knows nothing about Java and just uses the regular Linux way of loading shared libraries (the dynamic linker ld.so), which looks in LD_LIBRARY_PATH and some common directories like /usr/lib64.

I would probably go with using LD_LIBRARY_PATH set from a start script of your Java application. If you don't want to use a start script, you could in theory set LD_LIBRARY_PATH from within the process itself. However, Java does not allow to do this (there is only System.getenv(), not System.setenv()), so you would need to write a small C library that is called from Java and calls putenv() setting LD_LIBRARY_PATH.

If you build libclient.so itself, you can use the -rpath linker flag to specify a path where the dynamic linker should look for further required libraries. Be careful if you specify a relative path here, it will interpreted as relative to the current working directory of the running application, not relative to the location of libclient.so. To achieve this, you need to use $ORIGIN as argument for -rpath and be careful that your shell does not expand this.

So, if you want to have libclient.so and libhttp.so in the same directory, you need to use

-rpath '$ORIGIN'

as argument to the linker when building libclient.so. If you do not call the linker directly but let your compiler call it, you need to add the following to your compiler's command line:

-Wl,-rpath,'$ORIGIN'

More information about this can be found in the man page for ld.so.