JNI can't find shared library after program has been deployed

I am having troubles after moving an exported Java project from the development machine to the production.

The java project (an Eclipse plugin) has a JNI library written by me, which depends on a open source library, which in turn depends on Boost. I compiled everything, including Boost, on my SLES11 machine and the program just works.

When I move the program to another machine, I get the error:

java.lang.UnsatisfiedLinkError:/path/to/project/lib/libMyJNI.so: libboost_system.so.1.67.0: cannot open shared object file: No such file or directory

I copied the needed libraries in the same directory. ldd libMyJNI.so lists 20 dependencies but solves all of them.

I still get the same error.

I assume that java.library.path is correctly set, because it tries to load libMyJNI.so and recognize the dependencies.

Am I right expecting that if ldd works, java should solve the dependencies? Any clue?

Thank you!

EDIT: here's the output of ldd ldd libMyJNI.so

linux-vdso.so.1 =>  (0x00007fffa59ff000)
libboost_system.so.1.67.0 (0x00007fc427bce000)
libboost_filesystem.so.1.67.0 (0x00007fc4279b4000)
libboost_thread.so.1.67.0 (0x00007fc42778f000)
libboost_date_time.so.1.67.0 (0x00007fc42757a000)
libboost_iostreams.so.1.67.0 (0x00007fc42735f000)
libboost_serialization.so.1.67.0 (0x00007fc42710f000)
libboost_chrono.so.1.67.0 (0x00007fc426f06000)
libboost_atomic.so.1.67.0 (0x00007fc426d04000)
libboost_regex.so.1.67.0 (0x00007fc426a00000)
libpcl_common.so.1.8 (0x00007fc42673b000)
libpcl_io.so.1.8 (0x00007fc4263cb000)
libpcl_octree.so.1.8 (0x00007fc425fdc000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fc425c98000)
libm.so.6 => /lib64/libm.so.6 (0x00007fc425a42000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fc42582b000)
libc.so.6 => /lib64/libc.so.6 (0x00007fc4254cc000)
librt.so.1 => /lib64/librt.so.1 (0x00007fc4252c3000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc4250a6000)
libz.so.1 => /lib64/libz.so.1 (0x00007fc424e8f000)
libgomp.so.1 => /usr/lib64/libgomp.so.1 (0x00007fc424c86000)
libpcl_io_ply.so.1.8 (0x00007fc424a21000)
libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x00007fc4247f9000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc427fe8000)

Solution

Thanks to @user2543253 I have solved the problem. I am giving an answer for readers in the future (including me, when I will have the same problem).

java.library.path was correctly set, because it could load the JNI library. The other libraries (the dependencies) have to be in a directory listed in LD_LIBRARY_PATH. So when deploying the software, you can either

install the dependencies in places normally present in LD_LIBRARY_PATH or
append a directory to LD_LIBRARY_PATH before starting the plugin.

ldd could be successful in linking the library because it also looks in the current directory. So ldd libMyJNI.so could succeed while ldd \path\to\libMyJNI.so may fail. In this case, JNI won't work.