风中奇缘下载:linux静态库、共享库、搜索路径

来源：百度文库 编辑：九乡新闻网 时间：2024/04/29 23:18:01

 

2011-01-10 13:15:15| 分类： 默认分类 | 标签： |字号大中小 订阅

众所周知，静态链接 和动态链接各有不足，也各有千秋：
采用静态链接，最终可执行文件的Size会比较大，因为你在可执行文件中包含了一份程序所依赖的库中的符号的代码copy(注意：不是整个静态库的copy )。不过也恰是由于这点，可执行程序被部署到运行环境下后就简单多了，它运行时不需要再依赖任何其他库了，是典型的自我满足型。

而动态链接 则与静态链接恰恰相反，由于编译时仅仅是记录了其运行所依赖的共享库的名字而并未真正包含一份库的copy，所以这样的可执行文件的Size都较小，但在运行环境中我们需要先进行一番配置以让链接器能找到可执行程序所依赖的共享库。

但实际工作中，完全的采用静态链接有时是会遇到麻烦的。因为很多OS在默认安装时是不带开发包的，也就是说像libc、libpthread等系统库只提供了共享库版本(如/lib下提供了libc的共享库libc.so.6)，其静态库版本是需要自行下载、编译和安装的(如libc的静态库libc.a在安装后是放在/usr/lib下面的)。所以多数情况下，我们是将两种链接方式混合在一起使用的，至少像libc这样的系统库多是采用动态链接的。

共享库的制作方法很简单，用下面两行代码我们就可以得到一个名为libfoo.so的共享库：
gcc -fPIC -c libfoo.c -o libfoo.o
gcc -shared -o libfoo.so libfoo.o

不过不知道大家是否留意过：在/lib和/usr/lib等集中放置共享库的目录下，你总是会看到诸如下面的情况：
2010-12-10 12:28 libfoo.so -> libfoo.so.0.0.0*
2010-12-10 12:28 libfoo.so.0 -> libfoo.so.0.0.0*
2010-12-10 12:28 libfoo.so.0.0.0*

关于libfoo.so居然有三个文件入口，其中libfoo.so.0.0.0是真正的共享库文件，而其他两个文件入口则是指向libfoo.so.0.0.0的符号链接。为何会出现这个情况呢？这与共享库的命名惯例 和版本管理不无关系。

共享库的惯例中每个共享库都有多个名字属性，包括real name、soname和linker name：
real name - 指的是实际包含共享库代码的那个文件的名字(如上面例子中的libfoo.so.0.0.0)，也是在共享库编译命令行中-o后面的那个参数;

soname - 是shared object name的缩写，也是这三个名字中最重要的一个，无论是在编译阶段还是在运行阶段，系统链接器都是通过共享库的soname(如上面例子中的libfoo.so.0)来唯一识别共享库的。即使real name相同但soname不同，也会被链接器认为是两个不同的库。共享库的soname可在编译期间通过传给链接器的参数来指定，如上例中我们可以通过"gcc -shared -Wl,-soname -Wl,libfoo.so.0 -o libfoo.so.0.0.0 libfoo.o"来指定libfoo.so.0.0.0的soname为libfoo.so.0(在solaris上的命令为"gcc -shared -Wl,-h -Wl,libfoo.so.0 -o libfoo.so.0.0.0 libfoo.o")。ldconfig -n directory_with_shared_libraries命令会根据共享库的soname自动生成一个名为soname的符号链接指向real name文件，当然你也可以通过ln命令自己来创建这个符号链接。另外在linux下我们可通过readelf -d查看共享库的soname(在solaris下可使用dump -Lvp查看)，ldd输出的ELF文件依赖的共享库列表中显示的也是共享库的soname及所在路径。

linker name - 是编译阶段提供给编译器的名字(如上面例子中的libfoo.so)。如果你构建的共享库的real name是类似于上例中libfoo.so.0.0.0那样的带有版本号，那么你在编译器命令中直接使用-L path -lfoo是无法让链接器找到对应的共享库文件的，除非你为libfoo.so.0.0.0提供了一个linker name(如libfoo.so，一个指向libfoo.so.0.0.0的符号链接)。linker name一般在共享库安装时手工创建。

了解了共享库的名称惯例后，我们考虑如何使用这些共享库。使用共享库分为两个阶段，第一个阶段是可执行文件构建阶段。构建阶段我们需要为编译器(实为链接器)提供可执行程序依赖的共享库的位置信息：

如果依赖的共享库放置在链接器搜索的默认目录下(linux下一般依次为/lib和/usr/lib; solaris下依次为/usr/ccs/lib，/lib和/usr/lib)，你可以直接使用-l指定共享库的linker name即可；

如果依赖的共享库在非默认路径下，可使用-L来告知位置，比如gcc -o fooapp fooapp.c -L private_shared_lib_dir -lfoo，与默认目录相比，-L指定的目录优先级更高，另外注意：这里-L的位置信息并不记录在fooapp文件中，也不会对fooapp的执行产生影响；

在Solaris上，通过配置LD_LIBRARY_PATH也可以为编译器指定共享库路径，且其优先级比-L指定的路径更高，不过在Linux上LD_LIBRARY_PATH在编译阶段似乎不起作用。

运行时阶段，链接器同样要确定可执行文件依赖的共享库的位置和版本，不过与编译构造阶段不同，运行时的链接器按如下顺序搜索共享库：

-rpath
链接器优先在可执行文件中记录的rpath路径下搜索。rpath是在编译时传给链接器的路径参数：
linux平台下可使用：gcc -o fooapp fooapp.c -Wl,-rpath -Wl,fooapp_rpath -L foo_so_path -lfoo
solaris下可用：gcc -o fooapp fooapp.c -R fooapp_rpath -L foo_so_path -lfoo
多个路径可用冒号分割。编译成功后，这些信息会被记录在最终文件的RPATH节中，在运行时链接器读取RPATH节并搜索其值对应的目录。ldd 显示的是运行时应用依赖的库及其在运行环境下的确定路径，例如ldd fooapp的结果为：libfoo.so.0 => fooapp_rpath/libfoo.so.0 (0x00458000)

LD_LIBRARY_PATH
如果fooapp_rpath实际并不存在，则链接器会尝试在LD_LIBRARY_PATH配置的路径中查找依赖的共享库。

ldconfig配置的缓存中的路径
如果在rpath和LD_LIBRARY_PATH中依旧没有搜索到libfoo.so，那么链接器将尝试在ldconfig配置缓存中查找。linux平台上使用ldconfig配置搜索路径的方法如下：在/etc/ld.so.conf.d下增加一个自定义的链接器搜索路径配置文件，执行ldconfig更新缓存后生效。

系统默认路径
链接器最后将在默认路径下查找相关共享库，linux和solaris下均为/lib和/usr/lib。

如果在以上路径下依然没有找到libfoo.so，那么fooapp运行将出错。
linux静态库、共享库、搜索路径 linux静态库和共享库 linux-gcc 编译时头文件和库文件搜索路径 linux 静态库创建与使用 如何生成Linux下的静态库和动态库 Linux系统中如何添加自己的库文件路径 Linux下动态库静态库的使用 - mayqlzu的专栏 - CSDN博客 设置linux路径显示 Linux中vsFTP修改默认路径 linux下的静态函数库和动态函数库 Linux下配置静态IP地址，设置DNS和主机名 linux线程库 linux下搜索文件或文件夹 Linux操作系统下的常见系统资源共享 linux消息队列与共享内存编程 [ Linux进程通信 共享内存+信号量 动态库与静态库的原理介绍1 linux文件系统之路径查找与文件系统的挂载 在Linux下用Smbmount命令挂载Windows共享 计算机世界网-周报全文－ Linux局域网共享宽带上网 LINUX共享内存使用常见陷阱与分析2 LINUX共享内存使用常见陷阱与分析 一步一学Linux与Windows 共享文件Samba 【转】linux的消息队列与共享内存编程