有关LD_LIBRARY_PATH与ld.so.conf

我之前写过一篇关于LD_LIBRARY_PATH与gcc/g++ -L的关系的文章,于是我自己用CPACK制作了一个Debian安装包,然后我在/home/.bashrc里添加了export LD_LIBRARY_PATH=/usr/loca/lib:$LD_LIBRARY_PATH,再然后老大告诉我这个方法不行,打回重新想办法,经过一番寻找终于找到了---ld.so.conf可以完美解决这个问题。

 

首先说说,为什么LD_LIBRARY_PATH不行?可以看看老外是怎么说的

一般LD用在下面情况:

  • 升级共享库时,替换之前先测试一下
  • 类似的,升级后的某个程序可能依赖于一些动态链接库,如果你将某个链接库替换了,程序可能就无法工作了。这时候,你可以使用LD_LIBRARY_PATH指向存有备份的一个目录,然后,你可以没有顾忌地替换系统版本了。万一出错,拷贝回去就是了

感觉LD_LIBRARY_PATH就是临时使用的,为什么呢?因为LD_LIBRARY_PATH如果设置成全局的话,如果被破坏掉的,那么就会出现大规模的破坏。不要说这个变量不会改,但是这样做就是不妥的办法,网上大家可以找到许许多多的关于LD_LIBRARY_PATH不好的文章。这里就不再多说

 

但是,如果不让用LD_LIBRARY_PATH,我们该怎么办呢?

Linux系统为大家已经想好了办法,我们使用ld.so.conf来解决。我们已经知道linux在加载动态库的时候,会去标准路径下(/lib,/usr/lib)下去寻找应用程序用到的动态库。但对于我们那些不标准的路径下我们安装了lib库,例如我把我的库安装到了/usr/local/lib下了,我们怎么办呢?

 

Linux的通常做法是:将非标准路经加入 /etc/ld.so.conf,然后运行 ldconfig 生成 ld.so.cache。 Linux在加载共享库的时候,会从 ld.so.cache 查找。[ldconfig需要在root权限下执行]

所以,我们在安装了库,但是编译程序后,ldd发现链接不到库,那么我们就要查看你安装的库是否是非标准路径,如果是那么就把你的非标准路径加入到/etc/ld.so.conf文件中,然后调用ldconfig生成下ld.so.cache,就可以了。想查看下你的库是否已经在ld.so.cache中,可以这样 ldconfig -p | grep lib**就可以了。

 

对于,Ubuntu来说,还与其他的LINUX系统不一样,在/etc/ld.so.conf中只有一句include /etc/ld.so.conf.d/*.conf,也就是说它我们不能在/etc/ld.so.conf下添加,但是我们可以在/etc/ld.so.conf.d下新建一个*.conf在这里面添加你的非标准路径就可以了,记得调用sudo ldconfig 生成ld.so.cache文件就可以了

 

补充:


 

说说今天又遇到的问题:(cmake之后出现的问题)

问题1:/usr/bin/ld: warning: libboost_system.so.1.55.0, need by /usr/local/lib/libboost_thread.so, may conflict with libboost_system.so.1.48.0

            .....

问题2: `.text._ZN5boost16exceptions_detail10bad_alloc_D2Ev' refereced section `.text._ZN5boost16exceptions_detail10bad_alloc_D1Ev'..... of /usr/lib/gcc/x86_64-linux-gnu/4.8.2/../../../libboost_thread.a(thread.o)

 

这两个问题折腾我了一下午,这两个问题的变现不一样,其实他们都是一个问题造成的。

首先说说为什么会这样?

第一个问题:是由于系统里面在/usr/lib下面有一个libboost_system.so.1.48.0,而在/usr/local/lib下我安装了一个libboost_system.so.1.55.0,造成了g++链接时的冲突

第二个问题:是由于在/usr/lib下有一个libboost_thread.a,而我在/usr/local/lib下安装了libboost_thread.so.1.55.0,造成了g++链接的冲突错误。

 

现在问题来了,他们为什么会冲突呢?为什么呢?我们在编译程序的时候,gcc/g++是怎样搜索链接库呢?

经过仔细寻找,我们使用 ld --verbose | grep SEARCH_DIR会出现下面的内容

SEARCH_DIR("/usr/i686-linux-gnu/lib32"); SEARCH_DIR("=/usr/local/lib32"); SEARCH_DIR("=/lib32"); SEARCH_DIR("=/usr/lib32"); SEARCH_DIR("=/usr/local/lib/i386-linux-gnu"); SEARCH_DIR("=/usr/local/lib"); SEARCH_DIR("=/lib/i386-linux-gnu"); SEARCH_DIR("=/lib"); SEARCH_DIR("=/usr/lib/i386-linux-gnu"); SEARCH_DIR("=/usr/lib");

 

这就是gcc再编译的时候,所搜寻的库文件所在的路径,所以就出现了上面的问题。当gcc/g++在/usr/lib中发现这些库之后,就不再搜索了,然后就让gcc/g++链接了这些库,而我需要的正确的库应该在/usr/local/lib下,这就造成了链接了错误的库文件。

解决方法就是:删除掉/usr/lib下同名的不需要的或者版本过低的库文件(目前是这样做的,也许有更好的方法,知道的请告诉我)

 

上面查看gcc/g++/ld搜索路径还有其他方法:

            gcc -Wl,  --verbose 

            gcc --print-search-dirs

 

posted @ 2014-11-04 17:37 dahaol 阅读(...) 评论(...) 编辑 收藏