作为一名经常在Linux下从事开发的工程师来说，应该很多人都遇到过找不到so库的问题，特别是在一些涉及到C/C++依赖的项目中。在本公众号之前文章中介绍的使用Cython加速Python程序的例子中，Python这类解释型语言也会调用一些C/C++编译出来的so库。为了让大家能够面对例如下面这种错误时不再手足无措，我整理了这篇文章。

1	error while loading shared libraries: libxxx.so.2: cannot open shared object file: No such file or directory

Linux下so的版本机制介绍

如果大家在自己的linux系统上执行 ls -l /usr/lib64 这条命令，则会看到很多具有下列特征的软连接,其中x、y、z为数字, 那么这些软连接和他们后面的数字有什么用途呢？

1
2
3

libfoo.so    ->  libfoo.so.x
libfoo.so.x  ->  libfoo.so.x.y.z
libbar.so.x  ->  libbar.so.x.y

这里的x,y,z分别代表的是这个so的主版本号(MAJOR)，次版本号(MINOR)，以及发行版本号(RELEASE),对于这三个数字各自的含义，以及什么时候会进行增长，不同的文献上有不同的解释，不同的组织遵循的规定可能也有细微的差别，但有一个可以肯定的事情是：主版本号(MAJOR)不同的两个so库，所暴露出的API接口是不兼容的。而对于次版本号，和发行版本号，则有着不同定义，其中一种定义是：次要版本号表示API接口的定义发生了改变（比如参数的含义发生了变化），但是保持向前兼容；而发行版本号则是函数内部的一些功能调整、优化、BUG修复，不涉及API接口定义的修改。

几个so库有关名字的介绍

在开始这一节之前，我们先来做一个小的测试，屏幕不要往下滑动太多啊，要不你就提前看到答案了:)

问题：有如下几个so库的名字，你认为对于一个程序的运行，那个名字是最重要的呢？

libfoo.so
libfoo.so.1
libfoo.so.1.1
libfoo.so.1.1.1

从直觉上，我猜你选择了libfoo.so这个不带任何数字后缀的答案，但实际上，这个不带任何数字后缀的文件名可能是用处最少的一个文件，真正在一个程序的运行过程中起到定位到某一个so功能的，实际上是带有一个数字后缀的libfoo.so.1这种形式的文件名。为了证明我说的有道理，我们可以在linux下执行ldd命令来查看一个可执行文件到底都依赖了哪些so库，例如我们可以执行ldd /bin/bash来查看一下bash这个可执行文件运行时依赖的so库，在我的PC上输出结果如下：

$ ldd /bin/bash
	linux-vdso.so.1 =>  (0x00007ffffd0cc000)
	libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007fa2b3a49000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007fa2b3845000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fa2b3482000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fa2b3c73000)

可以看到，这里显示的都是形如libfoo.so.x这样带有一个数字后缀的文件

好了，下面我们来介绍在so查找过程中的几个名字：SONAME、real name、linker name,其中SONAME是业界通用名称，而real name和linker name这两个叫法是我从参考文献[1]中借鉴的。

SONAME 是一组具有兼容API的SO库所共有的名字，其命名特征是lib+<库名>+.so.+<数字>这种形式的
real name 是真实具有SO库可执行代码的那个文件，之所以叫real是相对于SONAME和linker name而言的，因为另外两种名字一般都是一个软连接，这些软连接最终指向的文件都是具有real name命名形式的文件。real name的命名格式中，可能有2个数字尾缀，也可能有3个数字尾缀，但这不重要。你只要记住，真实的那个，不是以软连接形式存在的，就是一个real name。例如下面的两个文件，libdns.so.100.1.1有1.9M大小，而libdns.so.100是一个软连接，所以libdns.so.100.1.1这个真实的文件的文件名就是real name
1
2
lrwxrwxrwx. 1 root root 17 Feb 7 2018 libdns.so.100 -> libdns.so.100.1.1
-rwxr-xr-x. 1 root root 1.9M Aug 4 2017 libdns.so.100.1.1
linker name 这个名字只是给编译工具链中的连接器使用的名字，和程序运行并没有什么关系，仅仅在链接得到可执行文件的过程中才会用到。它的命名特征是以lib开头，以.so结尾，不带任何数字后缀的格式

`SONAME`的作用

假设在你的Linux系统中有3个不同版本的bar共享库，他们在磁盘上保存的文件名如下：

/usr/lib64/libbar.so.1.3
/usr/lib64/libbar.so.1.5
/usr/lib64/libbar.so.2.1

假设以上三个文件，都是真实的so库文件，而不是软连接，也就是说，上面列出的名字都是real name。

根据我们之前对版本号的定义，我们可以知道：

libbar.so.1.3和libbar.so.1.5之间是互相兼容的
libbar.so.2.1和上述两个库之间互相不兼容

我们再假设你有两个不同的程序A和B，其中A程序依赖libbar.so.1.5这个库文件，而B程序依赖libbar.so.2.1这个库文件。但实际上，在A和B两个程序中，并没有写明自己所依赖的是libbar.so.1.5和libbar.so.2.1,真正保存在A和B中的是两个库的SONAME,也即libbar.so.1和libbar.so.2。然后，再通过软链接的形式，将libbar.so.1链接到libbar.so.1.5,将libbar.so.2链接到libbar.so.2.1。

那么引入软连接的好处是什么呢？假设有一天，libbar.so.2.1库进行了升级，但API接口仍然保持兼容，升级后的库文件为libbar.so.2.2，这时候，我们只要将之前的软连接重新指向升级后的文件，然后重新启动B程序，B程序就可以使用全新版本的so库了，我们并不需要去重新编译链接来更新B程序。

总结一下上面的逻辑：

通常SONAME是一个指向real name的软连接
应用程序中存储自己所依赖的SO库的SONAME,也就是仅保证主版本号能匹配就行
通过修改软连接的指向，可以让应用程序在互相兼容的SO库中方便切换使用哪一个
通常情况下，大家使用最新版本即可，除非是为了在特定版本下做一些调试、开发工作

`linker name`的作用

上一节中我们提到，可执行文件里会存储精确到主版本号的SONAME，但是在编译生成可执行文件的过程中，编译器怎么知道应该用哪个主版本号呢？为了回答这个问题，我们从编译链接的过程来梳理一下。

假设我们使用gcc编译生成一个依赖foo库的可执行文件A：

1	gcc A.c -lfoo -o A

熟悉gcc编译的读者们肯定知道，上述的-l标记后跟随了foo参数，表示我们告诉gcc在编译的过程中需要用到一个外部的名为foo的库，但这里有一个问题，我们并没有说使用哪一个主版本，我们只给出了一个名字。为了解决这个问题，软链接再次发挥作用，具体流程如下：

根据linux下动态链接库的命名规范，gcc会根据-lfoo这个标识拼接出libfoo.so这个文件名，这个文件名就是linker name，然后去尝试读取这个文件，并将这个库链接到生成的可执行文件A中。在执行编译前，我们可以通过软链接的形式，将libfoo.so指向一个具体so库，也就是指向一个real name，在编译过程中，gcc会从这个真实的库中读取出SONAME并将它写入到生成的可执行文件A中。例如，若libfoo.so指向libfoo.so.1.5,则生成的可执行文件A使用主版本号为1的SONAME,即libfoo.so.1。

在上述编译过程完成之后，SONAME已经被写入可执行文件A中了，因此可以看到linker name仅仅在编译的过程中，可以起到指定连接那个库版本的作用，除此之外，再无其他作用。

总结一下上面的逻辑：

通常linker name是一个指向real name的软连接
通过修改软连接的指向，可以指定编译生成的可执行文件使用那个主版本号so库
编译器从软链接指向的文件里找到其SONAME，并将SONAME写入到生成的可执行文件中
通过改变linker name软连接的指向，可以将不同主版本号的SONAME写入到生成的可执行文件中

探索可执行程序运行时的so加载过程

上一节我们详细讨论了编译过程中，编译器是如何将依赖信息写入到可执行文件的。在接下来的部分，我们讨论当应用被运行时，Linux操作系统是如何读取并使用这些依赖信息并最终加载依赖的so库的。

加载so的搜索路径及干预方式

当在linux系统中启动一个可执行文件时，首先发挥作用的是程序加载器(program loader)，这个加载器也是一个so文件，通常具有ld-linux.so.X这样的文件名，其中的X是版本号。大家可以回顾一下,在上文中我们用ldd /bin/bash查看了bash所依赖的so库有哪些，其中就有/lib64/ld-linux-x86-64.so.2这个文件。其实，你可以尝试用ldd去检查任何一个可执行文件，你都会看到这个加载器的影子。linux下的elf格式的可执行文件在运行时，首先加载ld-linux.so，再由这个加载器去加载其他的so文件，当其他so文件都已经加载完成之后，我们自己编写的main函数才会被执行。

加载器会在以下几个地方进行so库的搜索，搜索顺序为从上至下，如果这些信息不存在，或者在对应的路径下找不到能够加载的文件，那么就尝试下一项，如果所有的都找不到，那就会报出文章开头展示出的找不到so库的错误信息：

rpath 信息，编译链接时写入到可执行文件内部的数据
LD_LIBRARY_PATH 环境变量
runpath 信息，编译链接时写入到可执行文件内部的数据
/etc/ld.so.conf 文件中列出的路径
/lib、/usr/lib64 等系统默认路径

我们首先明确一点：绝大多数靠谱的应用程序都不会用到前面3项，仅依靠最后两项就可以运行，还有一些程序会用到前面3项，但是开发者已经提供好了对应的工具，使得用户不必去手工配置这些内容。而对于一些自己开发、内部使用、处于调试阶段的程序等，由于做的不够到位，可能导致需要配置前3项才可以让程序正常运行，而这种情况也往往是在工作中困扰我们最多的情况。

对于上述的rpath和runpath两项，都是在编译可执行文件时，由链接器写入到可执行文件中的信息，唯一的区别是这两项相对于LD_LIBRARY_PATH环境变量的位置，也就是说，rpath中指定的搜索路径不可以被LD_LIBRARY_PATH环境变量中指定的路径覆盖，而runpath中指定的内容却可以被覆盖。

rpath和runpath内可以记录一个绝对路径，也可以记录一个相对路径。其绝对路径的表达方式和linux操作系统一致，使用一个以/开头的路径，就可以表示这是一个绝对路径。但相对路径有两种表达形式，一种是以./开头，表示相对于当前的工作目录，另一种是使用$ORIGIN这个特殊的记号来开头，表示相对于可执行文件所在的位置。

那么，rpath是如何写入到可执行文件中的呢？以gcc为例，在使用gcc编译的过程中，可以通过-Wl开关向链接器传递-rpath参数来指定，例如下面的这一个命令，把$ORIGIN作为rpath写入到可执行文件中，即表示优先搜索可执行文件所在目录下有没有可以加载的so库, 其中的\$转义是为了避免shell将其理解为shell环境变量：

1	gcc -o main main.c -lfoo -L. -Wl,-rpath,"\$ORIGIN"

我们再来结合这个编译命令，来回顾一下上一节提到的几个名字：

-lfoo 告诉编译器，我需要一个叫做foo的库，于是gcc根据命名规则，拼接出libfoo.so这个linker name，但是去哪里找这个linker name呢？
-L. 告诉gcc，优先在当前工作目录下去找libfoo.so, 如果不指定这个，则gcc就会默认去/usr/lib64等默认路径去查找了。
- 前文说过，linker name通常是一个软连接，指向一个real name，这种情况在/usr/lib64等路径下很常见。但假设这里的libfoo.so也是一个我们刚刚编译生成的so文件，仅仅在开发阶段，我们也不关心什么版本管理问题，那么此时，可能软连接并不存在。这时libfoo.so本身既是linker name也是real name
编译器根据-L.的指示，在当前工作目录下找到了libfoo.so,并从中读取出了SONAME，假设为libfoo.so.1
编译器将SONAME libfoo.so.1 写入到生成的目标文件中
接下来，gcc调用链接器将目标文件和so库做链接，并生成最终的可执行文件。
由于-Wl,-rpath,"\$ORIGIN"命令的存在，gcc在调用链接器的时候，会把-rpath $ORIGIN这个参数传递给链接器，链接器将$ORIGIN作为rpath写入到最终生成的可执行文件中。
下面运行程序，程序开始运行，首先是加载器ld-linux.so被加载，加载器检查程序依赖的所有SONAME,发现程序依赖libfoo.so.1，但是去哪找这个so文件呢？
加载器发现可执行文件里有rpath信息，其内容为$ORIGIN，于是在可执行文件所在的目录下开始寻找所有的so文件，并检查其中的SONAME和可执行文件中记录的所依赖的SONAME是否匹配，如果匹配，则成功加载，如果不匹配，则尝试下一个
- 注意，这一步其实是有缓存的，从而加速程序的启动速度。缓存文件是/etc/ld.so.cache，有兴趣的同学可以man ld.so来了解详情

相比于rpath和runpath这两个被烙印到可执行文件中的配置而言，环境变量LD_LIBRARY_PATH就是一个非常易于修改的配置，因此，通过提供LD_LIBRARY_PATH环境变量，其实是我们解决找不到依赖库最常用的一个手段。

当然，rpath和runpath也是可以被修改的，有专用的工具如chrpath

例外情况

上述所介绍的搜索顺序，在绝大多数场景下都是适用的，但有一个场景不使用，即在使用setuid、setgid、chmod +s等手段，使得一个程序可以以root身份去执行的时候：

LD_LIBRARY_PATH环境变量会被忽略
rpath和runpath中包含$ORIGIN的会被忽略

以上原因是出于安全性考虑的，避免一个特权程序会因为环境变量的改变，或者文件被复制到其他路径，而加载了被恶意替换的so库。详细内容大家可以参考CVE-2010-3847，或者man ld.so。另外需要提示的是，ldd命令在执行时并不会受到这个安全策略的影响，所以，有两点需要注意：

有可能出现ldd报告显示依赖的so都可以找到，但实际执行这个文件就是报找不到的情况
ldd在检测依赖的时候，相当于以一种特殊的方式执行了那个可执行文件，因此存在安全隐患，建议不要对存在风险的可执行文件使用ldd查看其依赖

实际情况下的使用过程

对于绝大多数通过软件包管理器安装的程序，apt-get、yum这些工具，都会帮你把需要的so放到系统默认路径下，而且大部分应用也不需要将rpath烙印到可执行文件中，所以绝大多数情况下，仅使用上述介绍的最后两个搜索位置就可以找到需要的文件。

有一些奇特的开发者，比如知名的mozilla，传说他们的应用程序加载so库的路径不寻常，但mozilla提供了一个包装，在启动浏览器之前会帮我们临时设置好环境变量，所以作为用户来说，我们感知不到什么。

最有可能出现问题的，就是在我们自己的项目中引入了隔壁项目组开发的so库，或者从网上直接下载了一些tar包后解压缩直接使用，这时，如果出现问题，需要排查这几点：

so库的版本是否正确
LD_LIBRARY_PATH环境变量设置是否正确
在链接时，是否加入了rpath限定只能从特定位置加载so
是否在特权模式下运行

写在最后

上文中一直在提到SONAME，并且说一个库，可以有不同的版本，不同的主版本对应不同的SONAME，那么如何修改生成的so文件中的SONAME呢？答案是依然使用-Wl参数，指示链接器写入，具体示例如下：

1	gcc -shared -Wl,-soname,libfoo.so.233

此外，系统中的ldconfig命令可以帮我们来维护系统中的各种依赖关系的软连接，有兴趣的同学可以自己去深入研究。毕竟手动去创建那些软连接很容易出错。