linux应用层静态链接和动态链接（.a .so）

1、介绍

即使一个非常简单的程序，也需要依赖C标准库和系统库，链接其实就是把其他第三方库和自己源代码生成的二进制目标文件融合在一起的过程。经过链接之后，那些第三方库中定义的函数就能被调用执行了。早期的一些操作系统一般使用静态链接的方式，现在基本上都在使用动态链接的方式。

Windows环境：静态库是 .lib 文件，共享库是 .dll 文件
Linux环境：静态库是 .a 文件，共享库是 .so 文件（一般放在 /lib 或者 /usr/lib 目录下）

2、静态链接和动态链接

虽然静态链接和动态链接都能生成可执行文件，但两者的代价差异很大。

静态链接在链接的时候，就把所依赖的第三方库函数都打包到了一起，导致最终的可执行文件非常大。
而动态链接在链接的时候并不将所有的第三方库都打包到最终的可执行文件上，而是只记录用到了哪些动态链接库，在运行时才将从第三方库中读取自己所需的方法（将那些第三方库装载（Load）进来。装载是指将磁盘上的程序和数据加载到内存上。）。

例如下图中的Program 1，系统首先加载Program 1，发现它依赖libx.so后才去加载libx.so。
在这里插入图片描述
静态链接就是把所需的东西都带在了身上。动态链接只把精简后的内容带在自己身上，需要什么，运行的时候再去拿。

3、地址无关

无论何种操作系统上，使用动态链接生成的目标文件中凡是涉及第三方库的函数调用都是地址无关的。假如我们自己编写的程序名为Program 1，Program 1中调用了C标准库的printf()，在生成的目标文件中，不会立即确定printf()的具体地址，而是在运行时去装载这个函数，在装载阶段确定printf()的地址。这里提到的地址指的是进程在内存上的虚拟地址。动态链接库的函数地址在编译时是不确定的，在装载时，装载器根据当前地址空间情况，动态地分配一块虚拟地址空间。

而静态链接库其实是在编译时就确定了库函数地址。比如，我们使用了printf()函数，printf()函数对应有一个目标文件printf.o，静态链接时，会把printf.o链接打包到可执行文件中。在可执行文件中，printf()函数相对于文件头的偏移量是确定的，所以说它的地址在编译链接后就是确定的。

4、优缺点

4.1、动态链接的优缺点

相比之下，动态链接主要有以下好处：

多个可执行文件可以共享使用系统中的共享库。每个可执行文件都更小，占用的磁盘空间也相对比较小。而静态链接把所依赖的库打包进可执行文件，假如printf()被其他程序使用了上千次，就要被打包到上千个可执行文件中，这样会占用了大量磁盘空间。
共享库的之间隔离决定了共享库可以进行小版本的代码升级，重新编译并部署到操作系统上，并不影响它被可执行文件调用。静态链接库的任何函数有了改动，除了静态链接库本身需要重新编译构建，依赖这个函数的所有可执行文件都需要重新编译构建一遍。

当然，共享库也有缺点：

如果将一份目标文件移植到一个新的操作系统上，而新的操作系统缺少相应的共享库，程序将无法运行，必须在操作系统上安装好相应的库才行。
共享库必须按照一定的开发和升级规则升级，不能突然重构所有的接口，且新库文件直接覆盖老库文件，否则程序将无法运行。

动态库：以 lib 作为前缀，以 .so作为后缀。如 libxxx.so

4.1、静态链接的优缺点

静态库命令规则：以 lib 作为前缀，以 .a作为后缀。如 libxxx.a

优点：程序中已经包含了代码，运行时不需要再加载静态库，运行速度更快

缺点：占用更多的磁盘空间，静态库升级以后，程序需要重新编译链接。

5、ldd命令查看动态链接库依赖

在Linux上，动态链接库有默认的部署位置，很多重要的库放在了系统的/lib和/usr/lib两个路径下。一些常用的Linux命令非常依赖/lib和/usr/lib64下面的各个库，比如：scp、rm、cp、mv等Linux下常用的命令非常依赖/lib和/usr/lib64下的各个库。不小心删除了这些路径，可能导致系统的很多命令和工具都无法继续使用。

我们可以用ldd命令查看某个可执行文件依赖了哪些动态链接库。

leiting@ubuntu:~/code/tbox_ag35/BHAP.TBOX.B41V.APP/BHAP_TBOX_Code/Platform/src$ ldd /bin/ls
	linux-vdso.so.1 (0x00007ffc7aa40000)
	libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f53dc6ce000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f53dc4dc000)
	libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f53dc44b000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f53dc445000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f53dc732000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f53dc422000)

可以看到，我们经常使用的ls命令依赖了不少库，包括了C语言标准库libc.so。

如果某个Linux的程序报错提示缺少某个库，可以用ldd命令可以用来检查这个程序依赖了哪些库，是否能在磁盘某个路径下找到.so文件。如果找不到，需要使用环境变量LD_LIBRARY_PATH来调整，下文将介绍环境变量LD_LIBRARY_PATH。

6、SONAME文件命名规则

libname.so.x.y.z

lib是前缀，这是一个约定俗成的规则。x为主版本号（Major Version），y为次版本号（Minor Version），z为发布版本号（Release Version）。

Major Version表示重大升级，不同Major Version之间的库是不兼容的。Major Version升级后，或者依赖旧
Major Version的程序需要更新代码，重新编译，才可以在新的Major Version上运行；或者操作系统保留旧Major Version，使得老程序依然能运行。Minor Version表示增量更新，一般是增加了一些新接口，原来的接口不变。所以，在Major Version相同的情况下，Minor Version从高到低是兼容的。
Release Version表示库的一些bug修复，性能改进等，不添加任何新的接口，不改变原来的接口。

但是我们刚刚看到的.so只有一个Major Version，因为这是一个软连接，libname.so.x软连接到了libname.so.x.y.z文件上。

$ ls -l /lib/x86_64-linux-gnu/libpcre.so.3
/lib/x86_64-linux-gnu/libpcre.so.3 -> libpcre.so.3.13.2

因为不同的Major Version之间不兼容，而Minor Version和Release Version都是向下兼容的，软连接会指向Major Version相同，Minor Version和Release Version最高的.so文件上。

7、动态链接库查找过程

刚才提到，Linux的动态链接库绝大多数都在/lib和/usr/lib下，操作系统也会默认去这两个路径下搜索动态链接库。另外，/etc/ld.so.conf文件里可以配置路径，/etc/ld.so.conf文件会告诉操作系统去哪些路径下搜索动态链接库。这些位置的动态链接库很多，如果链接器每次都去这些路径遍历一遍，非常耗时，Linux提供了ldconfig工具，这个工具会对这些路径的动态链接库按照SONAME规则创建软连接，同时也会生成一个缓存Cache到/etc/ld.so.cache文件里，链接器根据缓存可以更快地查找到各个.so文件。每次在/lib和/usr/lib这些路径下安装了新的库，或者更改了/etc/ld.so.conf文件，都需要调用ldconfig命令来做一次更新，重新生成软连接和Cache。但是/etc/ld.so.conf文件和ldconfig命令最好使用root账户操作。非root用户可以在某个路径下安装库文件，并将这个路径添加到/etc/ld.so.conf文件下，再由root用户调用一下ldconfig。

对于非root用户，另一种方法是使用LD_LIBRARY_PATH环境变量。LD_LIBRARY_PATH存放着若干路径。链接器会去这些路径下查找库。非root可以将某个库安装在了一个非root权限的路径下，再将其添加到环境变量中。

动态链接库的查找先后顺序为：

LD_LIBRARY_PATH环境变量中的路径
/etc/ld.so.cache缓存文件
/usr/lib和/lib

比如，我们把CUDA安装到/opt下面，我们可以使用下面的命令将CUDA添加到环境变量里。

export LD_LIBRARY_PATH=/opt/cuda/cuda-toolkit/lib64:$LD_LIBRARY_PATH

如果在执行某个具体程序前先执行上面的命令，那么这个程序将使用这个路径下的CUDA；如果将这行添加到了.bashrc文件，那么该用户一登录就会执行这行命令，因此该用户的所有程序也都将使用这个路径下的CUDA。当同一个动态链接库有多个不同版本的.so文件时，可以将他们安装到不同的路径下面，然后使用LD_LIBRARY_PATH环境变量来控制使用哪个库。这种比较适合在多人共享的服务器上使用不同版本的库，比如CUDA这种版本变化较快，且深度学习程序又高度依赖的库。

除了LD_LIBRARY_PATH环境变量外，还有一个LD_PRELOAD环境变量。LD_PRELOAD的查找顺序比LD_LIBRARY_PATH还要优先。LD_PRELOAD里是具体的目标文件列表（A list of shared objects）；LD_LIBRARY_PATH是目录列表（A list of directories）。

8、GCC编译选项

使用GCC编译链接时，有两个参数需要注意，一个是-l（小写的L），一个是-L（大写的L）。我们前面曾提到，Linux有个约定速成的规则，假如库名是name，那么动态链接库文件名就是libname.so。在使用GCC编译链接时，-lname来告诉GCC使用哪个库。链接时，GCC的链接器ld就会前往LD_LIBRARY_PATH环境变量、/etc/ld.so.cache缓存文件和/usr/lib和/lib目录下去查找libname.so。我们也可以用-L/path/to/library的方式，让链接器ld去/path/to/library路径下去找库文件。

如果动态链接库文件在/path/to/library，库名叫name，编译链接的方式如下：

$ gcc -L/path/to/library -lname myfile.c

9、创建静态库

一个完整的库包含库文件本身、头文件、说明文档，现在我们仅需要关注前两者。一般制作动静态库只需要让程序进行到汇编阶段即可，即生成 .o 文件就可以停下来了。因为到了链接阶段，编译器就会去执行 main 函数的内容，制作库的时候没有这个东西。

制作动静态库的本质：就是将所有的.o文件打包。——》使用ar或者gcc打包

10、创建动态库

编译器在链接动态库的时候，是去指定目录下寻找的，可执行文件因为不包含库中代码，所以在编译的时候即便是指定了搜索目录也没有意义。
创建动态库使用的命令是：

# gcc -shared -o libxxx.so xxx.o xxx.o ... 
gcc -shared -o libhello.so hello.o add.o sub.o

10.1、使用动态库可能存在的问题

在链接阶段就会去找对应的动态库，但是此时即便我们添加了搜索路径也依然找不到动态库。
在这里插入图片描述
这是因为编译器只会去库目录和环境变量中找动态库，Linux环境下的库文件一般都放在 /lib 或者 /usr/lib 目录下，所以如果我们要让程序能找到动态库，可以使用接下来说的两种方法。

10.1.1、方法一：将生成的动态库拷贝到 /usr/lib 或者 /lib 目录下（不推荐）

这种方法不大推荐，因为会污染系统库源。

10.1.2、方法二：修改环境变量 LD_LIBRARY_PATH

环境变量 LD_LIBRARY_PATH是动态库的搜索路径，一般情况下为空，可执行文件运行时，会去这个环境变量中搜索动态库路径

注意：这种方法仅仅只是在当前 Shell 环境下有效，如果新开一个终端，相当于创建了一个新的Shell环境，该环境下的环境变量LD_LIBRARY_PATH是空的。