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
.