How to add .so file to the java.library.path in Linux
Use java -XshowSettings:properties to show the java.library.path (and others) value.
Thanks Jose, this helped me. I even found other important things with this java.library.path This path is lost after restarting the system, so I add it through /etc/profile file so that It automatically adds when the system restarts, even the CLASSPATH having related .jar files using these java.library.path .so files is overwritten by my application initiation’s/catalina.sh’s CLASSPATH, thus my application was complaining about the .jars and related .so’s. Problem is fixed once ClASSPATH has the required .jar file and also the required .so file in the java.library.path .
For the confused runners of java -XshowSettings:properties . My version of java prints out the properties, and then prints out —help . So I need to scroll up to see the settings.
Important note is to not have spaces for ‘equal’-sign. Novice users may copy the command straight off and wonder why they get a «not a valid identifier» error.
I had a lot of trouble figuring this out, please make sure that you have lib prefix in the library name.
- export LD_LIBRARY_PATH=»$LD_LIBRARY_PATH:/some/pathOfContainingDirectory»
- Rename libraries to have lib as a prefix. [Add this as part of build script]
mv JNIDemo.so libJNIDemo.so I used java -XshowSettings:properties method and found the path of a previously set folder and copied my so file to that folder
Hi @Ravindu I tried your approach. Its not working for me. I changed th permissions to 777 just to be sure. But nothing happens any suggestions?
I believe this to be a better way to do it as it only needs one single link to be created, no file edits needed, no exports or running of source before an application is run. And no bashrc lines needed.
That said, if you upgrade it may cause unintentional errors to future java releases as it might load an outdated library, although one link removal also solves this.
This works under ubuntu 18.04 with java 11 opensdk installed.
$ locate libjawt.so $ java -XshowSettings:properties From the two commands above, you can find the two paths you need to adjust this to your own system.
sudo ln -s /path/from/locate/libjawt.so /path/from/properties/libawt.so I made a symlink for java ll open sdk to find the library and mine was as follows because /usr/lib is one of the paths in the output. There is (in my output) a java path you may choose to use instead of /usr/lib if you want to keep java library (even symlinks) together.
sudo ln -s /usr/lib/jvm/java-11-openjdk-amd64/lib/libjawt.so /usr/lib/libjawt.so Where is the java folder for libraries on linux
Still don’t do it. Andrew is right. Only JARs from Oracle/Sun that extend the JDK belong there. Nothing of yours should ever end up in that folder.
I don’t think you should use ext lightly, but Oracle doesn’t seem to agree that they are the only ones to add extensions: docs.oracle.com/javase/tutorial/ext/index.html «Since this mechanism extends the platform’s core API, its use should be judiciously applied. Most commonly it is used for well standarized interfaces such as those defined by the Java Community Process, although it may also be appropriate for site wide interfaces.» And one of the sections in that trail is called «Creating and Using Extensions».
2 Answers 2
Use String extDir = System.getProperty(«java.ext.dirs»); to get the extensions dir path as you want (more info about system properties can be found here), set the path and write the jar files to that directory (be carefull to capture any IOException that could be raise in the writing process because this folders are usually write-protected or require root/admin privileges)
As quoted in the comments, this is something that should only be done in exceptional cases
As most comments say don’t do so, the alternative.
Most applications have an app.jar and a lib folder in which all library jars reside. In the application jar there is a META-INF/MANIFEST.MF with a class path including the lib jars.
As a developer I use maven (like ant, ivy) for the build infra structure and it does it just so. The jars are taken from the local maven repository else from the remote ones. Also maven uses a local repository of all jars in different versions. Jars missing in the remote repositories, like own programming, can be installed there.
BTW /usr/lib/jvm/ contains the java versions (do which java , which javac ).
Linked
Related
Hot Network Questions
Subscribe to RSS
To subscribe to this RSS feed, copy and paste this URL into your RSS reader.
Site design / logo © 2023 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2023.7.12.43529
By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.
Why java.library.path is not working on ubuntu?
I am working on an java component which need some libraries i.e .dll for windows system and .so files for Linux system. So I prepared an java application in netbeans and added some dependency jars and build the project. Execution on Windows: When I tried to run jar file on Windows system using command java -jar appName.jar I got java.lang.UnsatisfiedLinkError so I specified java.library.path while execution like java -Djava.library.path=full\\path\\to\\libs -jar appName.jar and it got run successfully on Windows. Execution on Linux(ubuntu) : When I tried to execute same jar file on ubuntu with the same command java -Djava.library.path=/path/to/libs -jar appName.jar I got error saying some .so file are not found on specified location (I checked file location and permissions, all is ok) Updated (added error):
ubuntu@ubuntu-HP-dx2480-MT-KL969AV:~/Desktop$ java -Djava.library.path=/home/ubuntu/Desktop/bin -jar JavaApplication4.jar initialize on Thread[AWT-EventQueue-0,6,main] with library path bin bin/jcef_helper: error while loading shared libraries: libcef.so: cannot open shared object file: No such file or directory
-rwxr-xr-x 1 ubuntu ubuntu 1483321 Jun 18 2014 cef.pak -rwxr-xr-x 1 ubuntu ubuntu 3258231 Jun 18 2014 devtools_resources.pak -rwxr-xr-x 1 ubuntu ubuntu 971264 Jun 11 2014 ffmpegsumo.dll -rwxr-xr-x 1 ubuntu ubuntu 9994752 Jun 11 2014 icudt.dll -rwxr-xr-x 1 ubuntu ubuntu 429568 Jun 18 2014 jcef.dll -rwxr-xr-x 1 ubuntu ubuntu 481488 Jun 18 2014 jcef_helper -rwxr-xr-x 1 ubuntu ubuntu 233984 Jun 18 2014 jcef_helper.exe -rwxr-xr-x 1 ubuntu ubuntu 53280768 Jun 11 2014 libcef.dll -rwxr-xr-x 1 ubuntu ubuntu 105317136 Jun 18 2014 libcef.so -rwxr-xr-x 1 ubuntu ubuntu 1309288 Jun 18 2014 libffmpegsumo.so -rwxr-xr-x 1 ubuntu ubuntu 1047296 Jun 18 2014 libjcef.so drwxrwxrwx 2 ubuntu ubuntu 4096 Dec 23 11:29 locales By some searching I come to know that I have try with LD_LIBRARY_PATH environment variable so I created an sh file having command:
export LD_LIBRARY_PATH=/path/to/libs java -jar /path/to/appName.jar and when I run sh file my program runs successfully. So my question is why java.library.path is not works for ubuntu (linux)? Is it like java.library.path is only for windows?
Difference between using java.library.path and LD_LIBRARY_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.