当我对共享库(如libphp5.so
)运行ldd
时,我看到它依赖于libmysqlclient.so.16
:
这些依赖文件名和路径(/usr/lib/mysql/libmysqlclient.so.16
)被烤到共享库二进制文件吗?或者这个路径是由其他方式确定的,比如通过/etc/ld.so.conf.d/mysql-i386.conf
,顺便包含:
/usr/lib/mysql/
还有一件事让我很困惑:
有一个我从源代码编译的共享库。这依赖于libmysqlclient_r
。gcc
编译器切换到生成如下这个库:
当我执行ldd mylib.so
时,我看到:
但是在/usr/lib/mysql
目录中我看到:
libmysqlclient_r.so
是指向libmysqlclient_r.so.16.0.0
的符号链接,那么为什么ldd
将依赖项显示为libmysqlclient_r.so.16
?我是不是错过了什么魔法?
作为一个多年的Windows开发人员,我对gcc
和Linux上的开发有点陌生。
我的Linux发行版是CentOS 6.0 x86-32bit.
您可以通过运行
查看路径来自何处LD_DEBUG=libs ldd ./libphp5.so
这些依赖文件名和路径(/usr/lib/mysql/libmysqlclient.so.16)是否被烘焙到共享库二进制文件中?
文件名几乎肯定是。路径通常不是。您可以通过
看到二进制文件中包含了什么内容readelf -d ./libphp5.so
查找(NEEDED)
和(RPATH)
条目
也给man ld.so
一个读取。有很多因素影响动态加载器如何搜索共享库:ld.so.conf
, LD_LIBRARY_PATH
,可执行文件是否为suid
, glibc是如何配置的,在链接时给出了哪些-rpath
设置,等等。
这些依赖文件名和路径(/usr/lib/mysql/libmysqlclient.so.16)是否被烘焙到共享库二进制文件中?
是的,它们可以而且经常是。这里的关键字是-rpath
。但是,ld.conf也有它的发言权。遗憾的是,整个系统相当复杂。