Java JNI可以';部署程序后找不到共享库

Java JNI可以';部署程序后找不到共享库,java,boost,java-native-interface,sles,Java,Boost,Java Native Interface,Sles,在将一个导出的Java项目从开发机器转移到生产机器之后,我遇到了麻烦 java项目(Eclipse插件)有一个由我编写的JNI库,它依赖于开源库,而开源库又依赖于Boost。我在我的SLES11机器上编译了所有的东西,包括Boost,程序运行正常 当我将程序移动到另一台机器时,我得到错误: java.lang.UnsatisfiedLinkError:/path/to/project/lib/libMyJNI.so: libboost_system.so.1.67.0: cannot open

在将一个导出的Java项目从开发机器转移到生产机器之后,我遇到了麻烦

java项目(Eclipse插件)有一个由我编写的JNI库,它依赖于开源库,而开源库又依赖于Boost。我在我的SLES11机器上编译了所有的东西,包括Boost,程序运行正常

当我将程序移动到另一台机器时,我得到错误:

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的输出

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)

多亏了@user2543253,我解决了这个问题。我会在将来给读者一个答案(包括我,当我遇到同样的问题时)

java.library.path
设置正确,因为它可以加载JNI库。其他库(依赖项)必须位于
LD\u LIBRARY\u PATH
中列出的目录中。因此,在部署软件时,您可以

  • 将依赖项安装在通常位于
    LD\u LIBRARY\u路径中的位置
  • 在启动插件之前,将目录附加到
    LD\u LIBRARY\u PATH

ldd
可以成功链接库,因为它也在当前目录中查找。因此
ldd libMyJNI.So
可能会成功,而
ldd\path\to\libMyJNI.So
可能会失败。在这种情况下,JNI将不起作用。

ldd是否会提升列表?可能它根本没有链接。链接器不会抱怨,因为在Linux中,假定所有需要的库都链接到可执行文件中。JNI库的情况并非如此。@user2543253是的,它列出了一些boost lib,一些来自开源库的lib,以及类似
libm.so
libc.so
。我不完全理解,我如何链接它?嗯,但它是否列出了错误消息所抱怨的确切文件?那是确切的档案吗?它可读吗?你是用不同的用户运行程序还是用sudo运行程序,这样它可能会得到不同的环境,如
ldd
?我被
ldd
输出搞糊涂了。我从未见过它列出没有
=>
和路径的库。没有像JNI链接器这样的东西。你说你想加载一个库,Java让OS加载器为你加载它。“java.library.path”也仅与实际的JNI库相关。操作系统看不到它的依赖性,也不会关心它
ld.so.conf
ld\u LIBRARY\u PATH
通常是唯一需要检查的内容。但是,您可以在Java中加载一个非JNI库,操作系统应该在解析依赖项时找到它,因为它已经在内存中了。也许您可以尝试从代码内部加载“问题”库,看看是否会得到更有用的错误消息。