JNI ne peut pas trouver la bibliothèque partagée après que le programme a été déployé

Question

Je rencontre des problèmes après avoir déplacé un projet Java exporté de la machine de développement vers la production.

Le projet Java (un plugin Eclipse) contient une bibliothèque JNI écrite par moi-même, qui dépend d'une bibliothèque open source, qui dépend à son tour de Boost. J'ai compilé tout, y compris Boost, sur mon ordinateur SLES11 et le programme fonctionne correctement.

Quand je déplace le programme vers un autre ordinateur, je reçois l'erreur :

java.lang.UnsatisfiedLinkError:/chemin/vers/projet/lib/libMyJNI.so: libboost_system.so.1.67.0: impossible d'ouvrir le fichier d'objet partagé : Aucun fichier ou dossier de ce type

J'ai copié les bibliothèques nécessaires dans le même répertoire. ldd libMyJNI.so liste 20 dépendances mais en résout toutes.

Je reçois toujours la même erreur.

J'assume que la variable java.library.path est correctement définie, car elle essaie de charger libMyJNI.so et reconnaît les dépendances.

Suis-je en droit de m'attendre à ce que si ldd fonctionne, Java devrait résoudre les dépendances? Une idée?

Merci!

ÉDITION : voici la sortie de 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)

Answer 1

Merci à @user2543253 j'ai résolu le problème. Je donne une réponse pour les lecteurs à l'avenir (y compris moi, quand j'aurai le même problème).

java.library.path était correctement défini, car il pouvait charger la bibliothèque JNI. Les autres bibliothèques (les dépendances) doivent être dans un répertoire répertorié dans LD_LIBRARY_PATH. Donc, lors du déploiement du logiciel, vous pouvez soit

• installer les dépendances aux endroits normalement présents dans LD_LIBRARY_PATH ou
• ajouter un répertoire à LD_LIBRARY_PATH avant de démarrer le plugin.

ldd pourrait réussir à lier la bibliothèque car il regarde également dans le répertoire actuel. Donc ldd libMyJNI.so pourrait réussir tandis que ldd \chemin\vers\libMyJNI.so pourrait échouer. Dans ce cas, JNI ne fonctionnera pas.