一文带你了解静态库和动态库

太过爱你忘了你带给我的痛 2021-12-21 14:47 263阅读 0赞

来源：公众号【编程珠玑】

作者：守望先生  
``[https://www.yanbinghu.com/2019/06/27/47343.html][https_www.yanbinghu.com_2019_06_27_47343.html]

## 前言 ##

我们在编写代码的时候经常用到已有的接口，他们是以库的形式提供给我们使用的，而常见形式有两种，一种常以.a为后缀，为静态库；另一种以.so为后缀，为动态库。那么这两种库有什么区别呢？

说明：本文主要说明Linux下的情况，windows不涉及。

## 目标文件 ##

在解释静态库和动态库之前，需要简单了解一下什么是目标文件。目标文件常常按照特定格式来组织，在linux下，它是ELF格式（Executable Linkable Format，可执行可链接格式），而在windows下是PE（Portable Executable，可移植可执行）。

而通常目标文件有三种形式：

我们来看一个简单实例：

//main.c#include<stdio.h>
    #include<stdio.h>
    #include<math.h>
    int main(int argc,char *argv[])
    {
        printf("hello 编程珠玑\n");
        int b = 2;
        double a = exp(b);
        printf("%lf\n",a);
        return 0;
    }

代码计算e的2次方并打印结果。由于代码中用到了exp函数，它位于数学库libm.so或者libm.a中，因此编译时需要加上-lm。

生成可重定位目标文件main.o:

$ gcc -c main.c   #生成可重定位目标文件
    $ readelf -h main.o  #查看elf文件头部信息
    ELF Header:
      Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
      Class:                             ELF64
      Data:                              2's complement, little endian
      Version:                           1 (current)
      OS/ABI:                            UNIX - System V
      ABI Version:                       0
      Type:                              REL (Relocatable file)
    (省略其他内容)

通过上面的命令将main.c生成为可重定位目标文件。通过readelf命令也可以看出来：Type为REL (Relocatable file)。

观察共享目标文件libm.so：

$ readelf -h /lib/x86_64-linux-gnu/libm.so.6
    ELF Header:
      Magic:   7f 45 4c 46 02 01 01 03 00 00 00 00 00 00 00 00 
      Class:                             ELF64
      Data:                              2's complement, little endian
      Version:                           1 (current)
      OS/ABI:                            UNIX - GNU
      ABI Version:                       0
      Type:                              DYN (Shared object file)
    （省略其他内容）

不同系统中libm.so的位置可能不一样，你可以通过locate命令来查找。locate命令的用法可参考《[Linux中的文件查找技巧][Linux]》。从结果可以看到，libm.so是共享目标文件（Shared object file）。

查看可执行目标文件main：

$ gcc -o main main.o -lm  #编译成最终的可执行文件
     $ readelf -h main         #查看ELF文件头ELF Header:
      Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
      Class:                             ELF64
      Data:                              2's complement, little endian
      Version:                           1 (current)
      OS/ABI:                            UNIX - System V
      ABI Version:                       0
      Type:                              EXEC (Executable file)
    (省略其他内容)

这里必须要强调一点，**如果使用到的函数没有在libc库中，那么你就需要指定要链接的库**，本文中需要链接libm.so或libm.a。可以看到，最终生成的main类型是Executable file，即可执行目标文件。

## 什么是静态库 ##

前面所提到可重定位目标文件以一种特定的方式打包成一个单独的文件，并且在链接生成可执行文件时，从这个单独的文件中“拷贝”它自己需要的内容到最终的可执行文件中。这个单独的文件，称为静态库。linux中通常以.a(archive)为后缀

还是拿前面的例子来说，我们使用静态链接构建我们的可执行文件：

$ gcc -c main.c
    $ gcc -static -o main main.o -lm

在这个过程中，就会用到系统中的静态库libm.a。这个过程做了什么呢？首先第一条命令会将main.c编译成**可重定位目标文件**main.o，第二条命令的static参数，告诉链接器应该使用静态链接，-lm参数表明链接libm.a这个库（类似的，如果要链接libxxx.a,使用-lxxx即可）。由于main.c中使用了libm.a中的exp函数，因此链接时，会将libm.a中需要的代码“拷贝”到最终的可执行文件main中。

特别注意，必须把-lm放在后面。放在最后时它是这样的一个解析过程：

那如果将-lm放在前面，又是怎样的情况呢？

如果把-lm放在前面，编译结果如下：

$ gcc -static -lm -o main main.o
    main.o: In function `main':
    main.c:(.text+0x2f): undefined reference to `exp'
    collect2: error: ld returned 1 exit status

更详细的解释也可以参考《[一个奇怪的链接问题][Link 1]》。

我们看看最终生成的文件大小：

$ ls -lh main
    -rwxrwxr-x 1 hyb hyb 988K 6月  27 20:22 main

生成的可执行文件大小为988k。ls的高级用法可参考《[ls命令常见实用用法][ls]》。

由于最终生成的可执行文件中已经包含了exp相关的二进制代码，因此这个可执行文件在一个没有libm.a的linux系统中也能正常运行。

## 什么是动态库 ##

动态库和静态库类似，但是它并不在链接时将需要的二进制代码都“拷贝”到可执行文件中，而是仅仅“拷贝”一些重定位和符号表信息，这些信息可以在程序运行时完成真正的链接过程。linux中通常以.so（shared object）作为后缀。

通常我们编译的程序默认就是实用动态链接：

$ gcc -o main main.c -lm  #默认使用的是动态链接

我们来看最终生成的文件大小：

$ ls -lh main
    -rwxrwxr-x 1 hyb hyb 8.5K 6月  27 20:25 main

可以看到，通过动态链接的程序**只有8.5k**！

另外我们还可以通过ldd命令来观察可执行文件链接了哪些动态库：

$ ldd main    linux-vdso.so.1 =>  (0x00007ffc7b5a2000)    
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe9642bf000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe963ef5000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fe9645c8000)

正因为我们并没有把libm.so中的二进制代码“拷贝”可执行文件中，我们的程序在其他没有上面的动态库时，将无法正常运行。

## 有什么区别 ##

到这里我们大致了解了静态库和动态库的区别了，静态库被使用目标代码最终和可执行文件在一起（它只会有自己用到的），而动态库与它相反，它的目标代码在运行时或者加载时链接。正是由于这个区别，会导致下面所介绍的这些区别。

可执行文件大小不一样

从前面也可以观察到，静态链接的可执行文件要比动态链接的可执行文件要大得多，因为它将需要用到的代码从二进制文件中“拷贝”了一份，而静态库仅仅是复制了一些重定位和符号表信息。

占用磁盘大小不一样

如果有多个可执行文件，那么静态库中的同一个函数的代码就会被复制多份，而动态库只有一份，因此使用静态库占用的磁盘空间相对比动态库要大。

扩展性与兼容性不一样

如果静态库中某个函数的实现变了，那么可执行文件必须重新编译，而对于动态链接生成的可执行文件，只需要更新动态库本身即可，不需要重新编译可执行文件。正因如此，使用动态库的程序方便升级和部署。

依赖不一样

静态链接的可执行文件不需要依赖其他的内容即可运行，而动态链接的可执行文件必须依赖动态库的存在。所以如果你在安装一些软件的时候，提示某个动态库不存在的时候也就不奇怪了。

即便如此，系统中一班存在一些大量公用的库，所以使用动态库并不会有什么问题。

复杂性不一样

相对来讲，动态库的处理要比静态库要复杂，例如，如何在运行时确定地址？多个进程如何共享一个动态库？当然，作为调用者我们不需要关注。另外动态库版本的管理也是一项技术活。这也不在本文的讨论范围。

加载速度不一样

由于静态库在链接时就和可执行文件在一块了，而动态库在加载或者运行时才链接，因此，对于同样的程序，静态链接的要比动态链接加载更快。所以选择静态库还是动态库是空间和时间的考量。但是通常来说，牺牲这点性能来换取程序在空间上的节省和部署的灵活性时值得的。再加上**局部性原理**，牺牲的性能并不多。

## 总结 ##

静态库和动态库具体是何如链接的已经超出了本文的介绍范围，本文仅简单介绍了一些静态库和动态库的区别，另外文中提到的在其他的linux系统，也指的是同样处理器架构的系统。但是了解这些基本信息，就能够帮助我们解决很多编译问题了。更多内容可自己阅读装载，链接方面的书籍。后面的文章也会介绍更多相关信息。

原文地址：[https://www.yanbinghu.com/2019/06/27/47343.html][https_www.yanbinghu.com_2019_06_27_47343.html]

## 本文相关阅读 ##

## 参考书籍 ##

关注公众号【编程珠玑】，获取更多Linux/C/C++/Python/Go/算法/工具等原创技术文章。后台免费获取经典电子书和视频资源

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg]

阅读原文查看最新内容。

[https_www.yanbinghu.com_2019_06_27_47343.html]: https://www.yanbinghu.com/2019/06/27/47343.html
[Linux]: http://mp.weixin.qq.com/s?__biz=MzI2OTA3NTk3Ng==&mid=2649284125&idx=1&sn=3a057bc7e23cc2db226068751f503bf3&chksm=f2f9ad7ac58e246cfc3de5e6b508aa24111d9184cdd8cadb790f4c98a3fef6d0e1ee3877221a&scene=21#wechat_redirect
[Link 1]: http://mp.weixin.qq.com/s?__biz=MzI2OTA3NTk3Ng==&mid=2649284434&idx=2&sn=9f6751b081c604cc327f5c4234d074ca&chksm=f2f9ac35c58e2523562d31aa93934d90076a50aa388d7bf2474b80f5582a37bc5e86aeaff525&scene=21#wechat_redirect
[ls]: http://mp.weixin.qq.com/s?__biz=MzI2OTA3NTk3Ng==&mid=2649283834&idx=1&sn=a1c50600d05d5cac21f3a2baadfe1c5c&chksm=f2f9af9dc58e268b89b3f07727747b98d67f8a16639fd84a0d714a52789e2bb857eb90ec0383&scene=21#wechat_redirect
[640_wx_fmt_jpeg]: /images/20211220/3d3ac4b1896d4d459a6737a1e9cd13cb.png