为什么 java.library.path 在 ubuntu 上不起作用？

Question

我正在开发一个 Java 组件，它需要一些库，即 Windows 系统的.dll和 Linux 系统的.so文件。 所以我在netbeans中准备了一个java应用，并添加了一些依赖jars并构建了项目。

在 Windows 上执行：

当我尝试使用命令java -jar appName.jar在 Windows 系统上运行 jar 文件时，我得到了java.lang.UnsatisfiedLinkError所以我在执行时指定了 java.library.path，如java -Djava.library.path=full\\\\path\\\\to\\\\libs -jar appName.jar并在 Windows 上成功运行。

在 Linux(ubuntu) 上执行：

当我尝试使用相同的命令java -Djava.library.path=/path/to/libs -jar appName.jar在 ubuntu 上执行相同的 jar 文件时，我收到错误消息，说在指定位置找不到某些 .so 文件（我检查了文件位置和权限，一切正常）

更新（添加错误）：

ubuntu@ubuntu-HP-dx2480-MT-KL969AV:~/Desktop$ java -Djava.library.path=/home/ubuntu/Desktop/bin -jar JavaApplication4.jar

使用库路径 bin bin/jcef_helper 在线程 [AWT-EventQueue-0,6,main] 上初始化：加载共享库时出错：libcef.so：无法打开共享对象文件：没有这样的文件或目录

包含 bin 文件夹

-rwxr-xr-x 1 ubuntu ubuntu   1483321 Jun 18  2014 cef.pak
-rwxr-xr-x 1 ubuntu ubuntu   3258231 Jun 18  2014 devtools_resources.pak
-rwxr-xr-x 1 ubuntu ubuntu    971264 Jun 11  2014 ffmpegsumo.dll
-rwxr-xr-x 1 ubuntu ubuntu   9994752 Jun 11  2014 icudt.dll
-rwxr-xr-x 1 ubuntu ubuntu    429568 Jun 18  2014 jcef.dll
-rwxr-xr-x 1 ubuntu ubuntu    481488 Jun 18  2014 jcef_helper
-rwxr-xr-x 1 ubuntu ubuntu    233984 Jun 18  2014 jcef_helper.exe
-rwxr-xr-x 1 ubuntu ubuntu  53280768 Jun 11  2014 libcef.dll
-rwxr-xr-x 1 ubuntu ubuntu 105317136 Jun 18  2014 libcef.so
-rwxr-xr-x 1 ubuntu ubuntu   1309288 Jun 18  2014 libffmpegsumo.so
-rwxr-xr-x 1 ubuntu ubuntu   1047296 Jun 18  2014 libjcef.so drwxrwxrwx 2 ubuntu ubuntu      4096 Dec 23 11:29 locales

通过一些搜索，我知道我已经尝试使用LD_LIBRARY_PATH环境变量，所以我创建了一个具有命令的 sh 文件：

export LD_LIBRARY_PATH=/path/to/libs

java -jar /path/to/appName.jar  

当我运行 sh 文件时，我的程序运行成功。

所以我的问题是为什么 java.library.path 不适用于 ubuntu (linux)？ 是不是像java.library.path只适用于 Windows？

Answer 1

所以我的问题是为什么 java.library.path 不适用于 ubuntu (linux)？ 是不是像 java.library.path 只适用于 Windows？

它确实有效，我们经常使用它。 使用-XshowSettings:properties启动您的应用程序并查看调试的搜索路径。

我们通常将库作为包部署到/usr/local/lib ，因为这些库也经常被其他组件使用。 不要忘记在将新库放入其中后调用ldconfig （对于export LD_LIBRARY_PATH部分而言如此）。

至于我记得应该是足够用只是添加文件夹-Djava.library.path如果我记错。 我会研究它，稍后告诉你澄清。

另外请发布readlink -f /home/ubuntu/Desktop/bin ， file /home/ubuntu/Desktop/bin/libcef.so和ldd /home/ubuntu/Desktop/bin/libcef.so 。

更新：我将尝试解释为什么事情有效，为什么无效。

让我们谈谈java.library.path 。 VM 使用此属性来查找库。 看看java.lang.System#load*(String libName)以供参考。 java.library.path属性预先设置了一些路径，以下显示了我的 ubuntu 框上的输出：

ortang@vbox-devel:~$ java -XshowSettings:properties
Property settings:
    ...
    java.library.path = /usr/java/packages/lib/amd64
        /usr/lib/x86_64-linux-gnu/jni
        /lib/x86_64-linux-gnu
        /usr/lib/x86_64-linux-gnu
        /usr/lib/jni
        /lib
        /usr/lib

请注意，使用此属性将覆盖现有属性。

ortwin@vbox-devel:~$ java -Djava.library.path=/some/other/folder:/yet/another/one -XshowSettings:properties
Property settings:
    ...
    java.library.path = /some/other/folder
        /yet/another/one

到现在为止还挺好。 JVM 只查看该属性中定义的文件夹！

您让 JVM 加载的库很可能依赖于其他库。 请注意，操作系统会查找这些依赖项，就像任何其他共享库一样！

因此，要解决您的问题，您必须确保您加载的库的依赖项已解决！ 使用ldd进行调试。

LD_LIBRARY_PATH环境变量执行类似的工作，因为它添加了操作系统将用于库查找的路径。 我不喜欢在生产环境中使用它。

Answer 2

我对您的问题的最佳猜测是您必须同时使用 java.library.path和LD_LIBRARY_PATH。 事实上，jlp 是让 java 加载你的 JNI 库，而 L_L_P 是让操作系统加载共享库和任何依赖库。 如果您的共享库依赖于其他路径中的其他库，您必须列出这些路径。

Answer 3

似乎 jcef 没有找到它的依赖项，尝试ldd libcef.so |grep "not found"和ldd libjcef.so |grep "not found"并修复丢失的库。 在我的机器上（ubuntu 14.04）它错过了 libudev.so.0 ，我的机器有/lib/x86_64-linux-gnu/libudev.so.1所以通过ln -s /lib/x86_64-linux-gnu/libudev.so.1 /lib/x86_64-linux-gnu/libudev.so.0欺骗它ln -s /lib/x86_64-linux-gnu/libudev.so.1 /lib/x86_64-linux-gnu/libudev.so.0和sudo ldconfig重新加载 ld 缓存。

Answer 4

我遇到了同样的问题，我使用了“-Djava.library.path”，但它不起作用。 我添加“-Dsun.boot.library.path”作为尝试，它有效！

尝试：

java -Dsun.boot.library.path=/path/to/libs -jar appName.jar