JNI не может найти общую библиотеку после развертывания программы - PullRequest
0 голосов
/ 29 июня 2018

У меня проблемы с переносом экспортированного проекта Java с компьютера разработчика на производство.

Проект Java (плагин Eclipse) имеет написанную мной библиотеку JNI, которая зависит от библиотеки с открытым исходным кодом, которая, в свою очередь, зависит от Boost. Я собрал все, включая Boost, на моем компьютере SLES11, и программа просто работает.

Когда я перемещаю программу на другой компьютер, я получаю сообщение об ошибке:

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

Я скопировал нужные библиотеки в один каталог. ldd libMyJNI.so перечисляет 20 зависимостей, но решает все из них.

Я все еще получаю ту же ошибку.

Я предполагаю, что java.library.path настроен правильно, потому что он пытается загрузить libMyJNI.so и распознать зависимости.

Правильно ли я ожидаю, что если ldd сработает, java должен решить зависимости? Любая подсказка?

Спасибо!

РЕДАКТИРОВАТЬ: вот вывод 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)

1 Ответ

0 голосов
/ 04 июля 2018

Благодаря @ user2543253 я решил проблему. Я даю ответ читателям в будущем (включая меня, когда у меня возникнет такая же проблема).

java.library.path был правильно установлен, потому что он мог загрузить библиотеку JNI. Другие библиотеки (зависимости) должны находиться в каталоге, указанном в LD_LIBRARY_PATH. Поэтому при развертывании программного обеспечения вы можете либо

  • установить зависимости в местах, обычно присутствующих в LD_LIBRARY_PATH или
  • добавьте каталог к ​​LD_LIBRARY_PATH перед запуском плагина.

ldd может быть успешным при связывании библиотеки, поскольку она также ищет в текущем каталоге. Так что ldd libMyJNI.so может быть успешным, в то время как ldd \path\to\libMyJNI.so может потерпеть неудачу. В этом случае JNI не будет работать.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...