As everyone might know, you have to set the java.library.path system property for making sure that you can load some JNI libraries in your java application. But often it wont be enough for you to specify java.library.path. The libraries which are referencing other shared libraries, would depend on standard way to resolve the libraries. Which means that if you have a foo.so which you are trying to load in your Java application, and foo.so references or is dynamically linked to bar.so, foo.so will look for the bar.so using the LD_LIBRARY_PATH.
java.library.path only works to resolve the immidiate native library that you are loading in your code. Loading of the other dependent libraries is left to the first library. The JNI library that you load will rely on the OS dependent way to resolve its references.
The catch is that, you will have to provide both java.library.path and LD_LIBRARY_PATH in such case for the libraries to load successfully. So its reliable to depend on the OS dependent way (LD_LIBRARY_PATH) of loading library files than java.library.path system property.
skip to main
|
skip to sidebar
2 comments :
Hey Kalpak, I have always wondered what LD_LIBRARY_PATH was used for.
Now I know.
--
Thanks
Parag
http://blog.adaptivesoftware.biz
Well, in general if you are running any native linux application and that application needs to load dynamically linked libraries (.so files) by default it would search on some predefined directories (like classpath) like /usr/lib /lib etc. But if you have any custom libraries which are not available on the default library paths, then you can export LD_LIBRARY_PATH (again as a custom classpath) in that shell before running application. So the application includes all the directories in LD_LIBRARY_PATH to lookup the dependent so files.
Post a Comment