《程序员的自我修养》第八章读书笔记

《程序员的自我修养》又回来了，作为一名程序员，我的修养还很不够，好了开始我们今天的主题。

本章主要对linux中共享库的组织与管理方法进行分析。

作为一个合格的软件产品就需要维护，既然有维护就一定有更新。共享库也不例外，开发者也会不断修正其中的bug或改进算法以提高共享库的性能。但要维护一个共享库的兼容性非常困难，因为此处的兼容性是指“ABI”兼容性。“ABI”是一个非常难以伺候的主，稍有不满意就会让共享库罢工。

既然共享库存在兼容性问题，那么保证依赖于这些共享库的应用程序能够正常运行就是一个必须要解决的问题。在linux下针对这一问题所采取的策略是“共享库版本”。

首先来看看共享库的命名规则：libname.so.x.y.z

其中x是主版本号，表示库的重大升级，不同主版本号的库之间不兼容，对于主版本升级的库，原有的应用程序必须重新编译；或者保留旧版的共享库。

y是次版本号，表示库的增量升级，即增加一些新的接口符号，且保持原本的符号不变。高的次版本号的库向后兼容低的次版本号的库。

z是发布版本号，表示库的一些错误的修正、性能的改进等，并不添加任何新的接口，也不对接口进行修改。相同主版本号、次版本号的共享库，不同的发布版本号之间完全兼容。

由于主版本号决定了一个程序能否正常运行，因此linux下采用SO-NAME机制来记录共享库的依赖关系。所谓依赖关系是指共享库的文件名去掉次版本号与发布版本号，仅保留主版本号。在linux系统中系统会为每个共享库在它所在的目录创建一个跟“SO-NAME”相同的并且指向它的软链接，这个软链接的目的在于总是指向主版本号相同而次版本号与发布版本号最新的共享库。如此一来就产生了两个方面的优势

1. 对于所有依赖于它的程序，仅需要记录这一SO-NAME即可，而不需要保留编译时所使用的共享库，如此一来就节省了大量的磁盘空间。
2. 同时当共享库升级时，就可以直接将新版的共享库替换掉旧版，同时修改软链接SO-NAME即可。

这里还要留心有关于glibc的符号名问题，由于某种原因，glibc 并没有遵守这套SO-NAME机制，请看ldd的运行结果如下：

libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6

这又是一个符号链接，上述符号链接的实际位置是：

/lib/x86_64-linux-gnu/libc-2.21.so

在我机器上的libc并没有发布版本号。

再来看看链接器，还是运行ldd：

/lib64/ld-linux-x86-64.so.2

这个符号链接的目标是：

/lib/x86_64-linux-gnu/ld-2.21.so

可以发现ld也没有验证按照SO-NAME机制的命名规则。

这个还要给大家介绍以下链接名，对于形如libXXX.so.2.6.1的库，在链接时我们可以使用-lXXX来指定。

虽然SO-NAME机制的引入带来了一定的好处，但这一方法无法解决次版本号交会问题，所谓次版本号交会问题是指当依赖于高次版本号的程序，运行于仅有较低次版本号共享库的系统是，就可能产生缺少某些符号的错误。但动态链接器在进行链接时，只进行主版本号的判断，即只判断SO-NAME，若SO-NAME相同，则认为运行环境符合条件。

对于8.2 节的具体内容就先给大家分析到这里，可能短期内我不太会用到这部分知识。

当前linux遵照FHS（File Hierarchy Standard）标准对共享库进行存放，主要位于以下三个位置：

/lib，这个位置主要存放系统最关键和基础的共享库，比如动态链接器、c语言运行库、数学库等，这些库主要是那些/bin和/sbin 下程序所要用到的库，还有系统启动时需要的库。

/usr/lib，这个目录下主要保存的是一些非系统运行时所需要的关键性的共享库，主要是一些开发时用到的共享库，这些共享库一半不会被用户程序或shell脚本直接用到。比如objdump这个工具就是在这个目录下。

/usr/local/lib，这个目录用来放置一些跟操作系统本身并不十分相关的库，主要是一些第三方的应用程序的库。与这些库相对于的可执行程序就放置在/usr/local/bin下。

对于一个在动态链接过程中所依赖的模块，其路径保存在“.dynamic”，对于这部分模块动态链接器的查找规则是：如果DT_NEED里面保存的是绝对路径，那么动态链接器就按照这个路径去查找；如果DT_NEED里面保存的是相对路径，那么动态链接器会在/lib、/usr/lib和由/etc/ld.so.conf 配置文件指定的目录中查找共享库。为了程序的可移植性和兼容性，共享库的路径往往是相对的。但如果遍历这些目录查找共享库的话，则查找的效率会非常低，特别是随着所安装的程序越来越多，ld.so.conf的内容会越来越多。因此为解决这一问题，linux 中存在一个 ldconfig 的程序。ldconfig 命令的用途：主要是在默认搜寻目录(/lib和/usr/lib)以及动态库配置文件/etc/ld.so.conf内所列的目录下，搜索出可共享的动态链接库(格式如前介绍,lib*.so*)，进而创建出动态装入程序(ld.so)所需的连接和缓存文件，缓存文件默认为 /etc/ld.so.cache，此文件保存已排好序的动态链接库名字列表。

以上内容引用这这一篇blog：http://blog.csdn.net/byrsongqq/article/details/6122546

程序在链接的时候首先从ld.so.cache中查找，然后再到ld.so.conf 的路径里边去详细找。

8.5 节主要分享了三个环境变量，分别是LD_LIBRARY_PATH、LD_PRELOAD、LD_DEBUG

改变共享库查找路径最简单的方法是使用LD_LIBRARY_PATH 环境变量，这个环境变量中包含的路径相当于链接时GCC的“-L”参数。

再让我们回过头来动态链接器的查找顺序：

1. 由LD_LIBRARY_PATH指定的路径；
2. 由/etc/ld.so.cache指定的路径；
3. 默认共享库目录，先/usr/lib，再/lib

 LD_PRELOAD 这一环境变量可以指定预先装载的一些共享库甚或是目标文件。这一环境变量指定的文件比LD_LIBRARY_PATH 所指定的文件还要优先，同时无论程序是否依赖于他们，该环境变量所指定的共享库或目标文件都会被装载。

书中给出了一种应用场景就是，结合全局符号介入机制的存在，优先装入的共享库或目标文件可以覆盖标准C库中的某个或某几个函数而不影响其他函数。

最后一个是LD_DEBUG，我认为也是最有用的一个，这个环境变量可以打开动态链接器的调试功能。可通过不同选项打印所需的信息。

给大家分享一个“symblos”选项，显示符号的解析过程。

8.6 主要对创建共享库过程所使用的编译选项进行分析。

其中新引入的一个编译选项是“-Wl”，这个参数可以将指定的参数传递给链接器。书中给出的一个例子是“-Wl，-soname，-my_soname”用于指定输出共享库的SO-NAME。

书中还提到了几点注意事项：

不要把输出共享库中的符号和调试信息去掉，也不要使用GCC的“-fomit-frame-pointer”选项，以上信息的缺失会造成调试工作的困难。

这里给大家分享几篇文章，有关于动态链接库的查找顺序，前文中给出的并不准确，在这里还要给大家区分以下“-L”、“-l”与“-rpath”、“LD_LIBRARY_PATH”之间的区别，前者是编译时用于查找共享库的路径与运行时共享库的查找无关，而后者才是动态链接器查找共享库的路径。“-rpath”会写入动态链接库的“.dynamic”段，“而LD_LIBRARY_PATH”仅用于动态链接库的查找。

http://blog.csdn.net/dbzhang800/article/details/6918413

使用strip可以清除共享库或可执行文件中的符号和调试信息。