linux加载共享程序,Linux下动态共享库加载时遇到的问题解决方案及原理

在java调用jni或者JNA时候&＃xff0c;报

error while loading shared libraries: libprint.so: cannot open shared object file: No such file or directory。这便是典型的找不到动态库的错误.

具体说来&＃xff0c;动态链接器ld.so按照下面的顺序来搜索需要的动态共享库&＃xff1a;

1&＃xff0e;ELF可执行文件中动态段中DT_RPATH所指定的路径。这实际上是通过一种不算很常用&＃xff0c;却比较实用的方法所设置的&＃xff1a;编译目标代码时&＃xff0c;可以对gcc加入链接参数“-Wl,-rpath”指定动态库搜索路径&＃xff1b;

2&＃xff0e;环境变量LD_LIBRARY_PATH指定的动态库搜索路径&＃xff1b;

3&＃xff0e;/etc/ld.so.cache中所缓存的动态库路径(如果支持ld.so.cache的话)。这可以通过修改配置文件/etc/ld.so.conf中指定的动态库搜索路径来改变&＃xff1b;

4&＃xff0e;默认的动态库搜索路径/lib&＃xff1b;

5&＃xff0e;默认的动态库搜索路径/usr/lib。

在嵌入式Linux系统的实际应用中&＃xff0c;1和2被经常使用&＃xff0c;也有一些相对简单的的嵌入式系统会采用4或5的路径来规范动态库。3在嵌入式系统中使用的比较少&＃xff0c;因为有很多系统根本就不支持ld.so.cache。

4和5的方式非常简单&＃xff0c;只要将所需要的库放到/lib或/usr/lib就可以解决找不到库的问题&＃xff0c;不过对于大一些的系统来说&＃xff0c;不太方便管理。1和2的方式要稍微复杂一些。

项目中使用到JNI来加载本地库&＃xff0c;项目自身(web使用)和对外接口(不是web使用)都用到相同的DLL&＃xff0c;当web使用访问正常时&＃xff0c;接口访问就报错&＃xff1b;相反当接口访问正常时&＃xff0c;web使用也会报错。错误信息&＃xff1a;java.lang.UnsatisfiedLinkError: Native Library XX.dll already loaded in another。

分析&＃xff1a;这种错误在我们使用热启动方式发布某个使用了JNI技术的Web应用时&＃xff0c;并将调用年native方法的jar包独立部署在该应用下面&＃xff0c;当我们的Web应用有了更新以后&＃xff0c;在调用到该jar包封装的native方法时&＃xff0c;会抛出该错误。(以上OS为Windows&＃xff0c;若是Linux或Unix&＃xff0c;应该是xxx.so 报错) 这是因为Web服务器已经在第一次加载该应用时&＃xff0c;已经load了该dll&＃xff0c;当该应用被再次热启动时&＃xff0c;该dll将重新被加载&＃xff0c;于是报错。解决方案&＃xff1a; 一、将含有JNI调用的jar包部署在Web服务器的公用lib库中。Web应用再发布时可以不用加载&＃xff1b;二、jar包部署不变&＃xff0c;在该Web中实现一个listener&＃xff0c;监听是否第一次启动&＃xff0c;若不是第一次启动&＃xff0c;屏蔽掉该jar包所含dll的加载。

1、原因

查询资料后才得知&＃xff1a;Java虚拟机为了在JNI本地库中确保基于classloader的命名空间隔离&＃xff0c;因而不允许一个JNI本地库被两个不同的classloader加载。而JBoss中web应用的classloader是独立的&＃xff0c;也就是说每个web应用都有一个专属的classloader&＃xff0c;这样就出现两个classloader加载同一JNI本地库的情况。

2、解决方法

解决这个问题其实很简单&＃xff0c;将访问到jni的代码单独提取出来&＃xff0c;并不直接让项目自身的classLoader加载&＃xff0c;则是让其由systemLoader加载 即可。一种方法就是将这部分代码&＃xff0c;单独封装成一个jar&＃xff0c;放到java的systemLoader可以加载的地方&＃xff0c;如lib/ext目录下。然后&＃xff0c;项目中 仍然去调用此代码。由于访问dll的代码由systemLoader加载&＃xff0c;因此&＃xff0c;多个项目同时访问同一个dll时&＃xff0c;即可避免再次加载了。因为&＃xff0c;第二个项目 在访问时&＃xff0c;寻找到的类&＃xff0c;已经被systemLoader加载过了&＃xff0c;因此项目本身的classLoader就不会再去加载这个类了。

在Weblogic中&＃xff0c;虽然不同的web应用使用不同的classloader&＃xff0c;但是web应用classloader的父classloader是相同的&＃xff0c;这样根据双亲委托模型只要让父classloader加载JNI本地库就可以避免被多个classloader加载。将so放在共享目录(System.getProperty("java.library.path"))的lib目录的并采用System.loadLibrary(libName)即可。

重新Weblogic问题就可以解决。

HPUX环境&＃xff0c;在WebLogic服务器中使用java调用C动态连接库异常问题总结

总结1&＃xff1a;查看服务器环境变量是否设置

SHLIB_PATH&＃xff0c;此环境变量设置为HPUX默认的查找路径&＃xff0c;配置为动态连接库的路径。

LD_LIBRARY_PATH&＃xff0c;此为LINUX设置的路径。

注意&＃xff1a;

此环境变量不一定非得设置&＃xff0c;可以用java.library.path来查看当前的路径指向哪里&＃xff0c;可以将动态连接库拷到java.library.path指定的目录即可。

总结2&＃xff1a;查看so文件是否有启动权限&＃xff0c;如果没有则会报权限问题。

测试方法&＃xff1a;可以使用System.loadLibrary(“XXXXX.so”)来进行测试&＃xff0c;如果正常通过则无异常显示&＃xff0c;如果有异常&＃xff0c;则根据提示来进行相应的更改。

测试时会提示是不在路径中&＃xff0c;还是别的什么异常。

基础知识&＃xff1a;

在把本机调用链接到对应的本机定义时&＃xff0c;类装入器扮演着重要角色。如果程序试图装入一个不存在或者放错的本机库时&＃xff0c;在链接阶段的解析过程会发生 UnsatisfiedLinkError。JVM 规范指定 UnsatisfiedLinkError 是&＃xff1a;

对于声明为 native 的方法&＃xff0c;如果 Java 虚拟机找不到和它对应的本机语言定义&＃xff0c;就会抛出该异常。 当调用本机方法时&＃xff0c;类装入器会尝试装入定义了该方法的本机库。如果找不到这个库&＃xff0c;就会抛出这个错误。

本机库的装入由调用 System.loadLibrary() 方法的类的类装入器启动 —— 在清单 6 中&＃xff0c;就是 UnsatisfiedLinkErrorTest 的类装入器。根据使用的类装入器&＃xff0c;会搜索不同的位置&＃xff1a;

对于由 bootstrap 类装入器装入的类&＃xff0c;搜索 sun.boot.library.path。

对于由扩展类装入器装入的类&＃xff0c;先搜索 java.ext.dirs&＃xff0c;然后是 sun.boot.library.path&＃xff0c;然后是 java.library.path。

对于由系统类装入器装入的类&＃xff0c;搜索 sun.boot.library.path&＃xff0c;然后是 java.library.path。

在清单 6 中&＃xff0c;UnsatisfiedLinkErrorTest 类是由系统类装入器装入的。要装入所引用的本机库&＃xff0c;这个类装入器先查找 sun.boot.library.path&＃xff0c;然后查找 java.library.path。因为在两个位置中都没有需要的库&＃xff0c;所以类装入器抛出 UnsatisfiedLinkageError。

当使用System.loadLibrary()调用 Dll&＃xff0c;两种方法:

1.设定环境变量。

比如&＃xff1a;所编辑的Dll在目录“D:/cppProjects/nativecode/release”内&＃xff0c;将这个路径复制添加到电脑的环境变量中的path变量内即可。

2.设定项目属性。(开发推荐)

右击项目名|选择属性properties|在左边列表内选择“Java Build Path”|在右边选项卡用选择“source”|点开项目名前的“&＃43;”号,选择“Native library location”&＃xff0c;“Edit”选择上面“D:/cppProjects/nativecode/release”路径。(当然如果将dll拷贝到workspace下也可以用相对路径。也可右击“src”设定其properties内Native Library项。)

System.load 和 System.loadLibrary详解

1.它们都可以用来装载库文件&＃xff0c;不论是JNI库文件还是非JNI库文件。在任何本地方法被调用之前必须先用这个两个方法之一把相应的JNI库文件装载。

2.System.load 参数为库文件的绝对路径&＃xff0c;可以是任意路径。

例如你可以这样载入一个windows平台下JNI库文件&＃xff1a;

System.load("C://Documents and Settings//TestJNI.dll");。

3. System.loadLibrary 参数为库文件名&＃xff0c;不包含库文件的扩展名。

例如你可以这样载入一个windows平台下JNI库文件

System. loadLibrary ("TestJNI");

这里&＃xff0c;TestJNI.dll 必须是在java.library.path这一jvm变量所指向的路径中。

可以通过如下方法来获得该变量的值&＃xff1a;

System.getProperty("java.library.path");

默认情况下&＃xff0c;在Windows平台下&＃xff0c;该值包含如下位置&＃xff1a;

1)和jre相关的一些目录

2)程序当前目录

3)Windows目录

4)系统目录(system32)

5)系统环境变量path指定目录

4.如果你要载入的库文件静态链接到其它动态链接库&＃xff0c;例如TestJNI.dll 静态链接到dependency.dll, 那么你必须注意&＃xff1a;

1)如果你选择

System.load("C://Documents and Settings// TestJNI.dll");

那么即使你把dependency.dll同样放在C://Documents and Settings//下&＃xff0c;load还是会因为找不到依赖的dll而失败。因为jvm在载入TestJNI.dll会先去载入TestJNI.dll所依赖的库文件dependency.dll&＃xff0c;而dependency.dll并不位于java.library.path所指定的目录下&＃xff0c;所以jvm找不到dependency.dll。

你有两个方法解决这个问题&＃xff1a;一是把C://Documents and Settings//加入到java.library.path的路径中&＃xff0c;例如加入到系统的path中。二是先调用

System.load("C://Documents and Settings// dependency.dll"); 让jvm先载入dependency.dll&＃xff0c;然后再调用System.load("C://Documents and Settings// TestJNI.dll");

2)如果你选择

System. loadLibrary ("TestJNI");

那么你只要把dependency.dll放在任何java.library.path包含的路径中即可&＃xff0c;当然也包括和TestJNI.dll相同的目录。