Difference Between Using Java.Library.Path and Ld_Library_Path

Difference between using java.library.path and LD_LIBRARY_PATH

The first form

-Djava.library.path=/path

will be handled in java bytecode level, System.loadLibrary will call Runtime.loadLibary, then will call java/lang/ClassLoader.loadLibrary. In the function call ClassLoader.loadLibrary, the system property java.library.path will be checked to get the full path of the library and pass this full path to native code to call system api dlopen/dlsym, eventually make the library loaded. You can browse the source from OpenJDK repository. The following code snippet is the segment I copy from the link.

The advantage of this form is that you will get error or warning or exception in Java code, if there are some problems with your library path.

// Invoked in the java.lang.Runtime class to implement load and loadLibrary.
static void loadLibrary(Class fromClass, String name,
boolean isAbsolute) {
ClassLoader loader =
(fromClass == null) ? null : fromClass.getClassLoader();
if (sys_paths == null) {
usr_paths = initializePath("java.library.path");
sys_paths = initializePath("sun.boot.library.path");
}
if (isAbsolute) {
if (loadLibrary0(fromClass, new File(name))) {
return;
}
throw new UnsatisfiedLinkError("Can't load library: " + name);
}
// ....

The second form

export LD_LIBRARY_PATH=/path

will be handled in native, according to the document of dlopen/dlsym

 dlopen()
The function dlopen() loads the dynamic library file named by the null-terminated string filename and returns an opaque "handle" for the
dynamic library. If filename is NULL, then the returned handle is for the main program. If filename contains a slash ("/"), then it is
interpreted as a (relative or absolute) pathname. Otherwise, the dynamic linker searches for the library as follows (see ld.so(8) for fur‐
ther details):

o (ELF only) If the executable file for the calling program contains a DT_RPATH tag, and does not contain a DT_RUNPATH tag, then the
directories listed in the DT_RPATH tag are searched.

o If, at the time that the program was started, the environment variable LD_LIBRARY_PATH was defined to contain a colon-separated list of
directories, then these are searched. (As a security measure this variable is ignored for set-user-ID and set-group-ID programs.)

In this manner, if there are some problems with your library path and the system can't load your library, the system won't give too much clue what happen and will fail silently (I guess). It depends whether or not to implement LD_LIBRARY_PATH, Android didn't use LD_LIBRARY_PATH to determine the library location, you can see Android's implementation from here.

What is LD_LIBRARY_PATH and how to use it?

Typically you must set java.library.path on the JVM's command line:

java -Djava.library.path=/path/to/my/dll -cp /my/classpath/goes/here MainClass

tell java location of library

Kindly make sure native HDF5 c libraries in /usr/lib or /usr/lib64 The program makes use of these native c libraries.

https://github.com/WimS83/XSQConverter/blob/master/src/xsqconvertergit/interfaces/librariesZipped/hdf5_native_libs.zip .

Why java.library.path is not working on ubuntu?


So my question is why java.library.path is not works for ubuntu (linux)? Is it like java.library.path is only for windows?

It does work, we use it a lot. Start your application with -XshowSettings:properties and take a look at the search path for debugging.

We usually deploy the libraries as a package to /usr/local/lib, since the libraries are often used by other components too. Don't forget to call ldconfig after placing a new library in there (so much for the export LD_LIBRARY_PATH part).

As far as i remember it should be enough with just adding the folder with -Djava.library.path if i recall correctly. I will look into it and tell you later to clarify.

Also please post readlink -f /home/ubuntu/Desktop/bin, file /home/ubuntu/Desktop/bin/libcef.so and ldd /home/ubuntu/Desktop/bin/libcef.so.

Update:
I will try to explain why things work and why not.

Lets talk about java.library.path. This property is used by the VM for looking up libraries. Take a look at java.lang.System#load*(String libName) for reference. The java.library.path property has some paths pre-set, the following shows the output on my ubuntu box:

ortang@vbox-devel:~$ java -XshowSettings:properties
Property settings:
...
java.library.path = /usr/java/packages/lib/amd64
/usr/lib/x86_64-linux-gnu/jni
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
/usr/lib/jni
/lib
/usr/lib

Be aware that using this property will overwrite the existing property.

ortwin@vbox-devel:~$ java -Djava.library.path=/some/other/folder:/yet/another/one -XshowSettings:properties
Property settings:
...
java.library.path = /some/other/folder
/yet/another/one

So far so good. The JVM is looking only in the folders defined in that property!

The libraries you make the JVM to load will most likely have dependencies to other libraries. Be aware that these dependencies are looked up by the operating system, just as any other shared library!

So to solve your problem you have to make sure that the libraries you load have their dependencies resolved! Use ldd for debugging that matter.

The LD_LIBRARY_PATH environment variable does a similar job, as it adds paths that will be used for library lookup by the OS. I am no fan of using it in production environments.

How to add .so file to the java.library.path in Linux

Add the containing directory to LD_LIBRARY_PATH before launching the application

        export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/some/pathOfContainingDirectory

Use java -XshowSettings:properties to show the java.library.path (and others) value.

Default Java library path?

Its default value depends on the operating system:

  • On Windows, it maps to PATH
  • On Linux, it maps to LD_LIBRARY_PATH
  • On OS X, it maps to DYLD_LIBRARY_PATH


Related Topics



Leave a reply



Submit