【linux系统】动静态库

库的理解

我写好了一份源代码，包含一系列.h, .c文件，现在我想交给其他人使用，怎么做？

直接给.h .c文件。这个做法不推荐，下图是c/c++文件编译链接过程

不推荐的原因之一：在大型项目中，如果每次编译都需要重新编译所有的 .c 文件，编译时间会非常长。

那我们不直接给 .h .c文件, 而是提前将.c 编译为 .o文件，再交给对方。这么做很好，要是再进一步就更完美，将所有的.o文件打个包，便得到了库。

c/c++有2中链接方式，编译时链接和运行时链接，根据不同的链接方式，库分为静态库和动态库

• 在编译时链接 – 静态库
• 在运行时链接 – 动态库

下面介绍如何制作、使用静态库和动态库

静态库

静态库：程序在编译链接的时候把库的代码链接到可执行文件中。程序运行的时候将不再需要静态库。

制作静态库

现在有两个文件：test.h, test.c，如下。

root@iZbp1inz4ol3gjahpjal9qZ:~/study# cat test.h
#include <stdio.h>

void Print();
root@iZbp1inz4ol3gjahpjal9qZ:~/study# cat test.c
#include "test.h"
void Print()
{
    printf("66666666\n");
}

制作静态库的流程如下：

执行上述命令后，结果如下：lib目录里存储制作的静态库。

root@iZbp1inz4ol3gjahpjal9qZ:~/study# make
gcc -o test.o -c test.c 
ar -rc libtest.a test.o
root@iZbp1inz4ol3gjahpjal9qZ:~/study# make put
mkdir -p lib/include
mkdir -p lib/mylib
cp *.h lib/include
cp *.a lib/mylib
root@iZbp1inz4ol3gjahpjal9qZ:~/study# make clean
rm -f *.o *.a
root@iZbp1inz4ol3gjahpjal9qZ:~/study# ls
lib  Makefile  test.c  test.h
root@iZbp1inz4ol3gjahpjal9qZ:~/study# tree lib
lib
├── include
│   └── test.h
└── mylib
    └── libtest.a

2 directories, 2 files

使用静态库

现在我们创建main.c来测试我们的静态库。如下：

root@iZbp1inz4ol3gjahpjal9qZ:~/study# cat main.c
#include "test.h"
int main()
{
    Print();
    return 0;
}root@iZbp1inz4ol3gjahpjal9qZ:~/study# gcc -o main main.c
main.c:1:10: fatal error: test.h: No such file or directory
    1 | #include "test.h"
      |          ^~~~~~~~
compilation terminated.

这里出现了一个报错，找不到头文件。原因很简单，test.h与main.c不在同一级目录下，此时我们有3种做法：

1. 告诉编译器，除了在当前目录下、系统目录下找，如果找不到，就去指定目录下找。参数-I [路径】
gcc main.c -o main -I ./lib/include
2. include头文件时，带相对路径或绝对路径
   include "lib/include/test.h"
3. 安装到系统里，即将头文件和库移到/usr/inlcude 和/usr/lib64, 如果不想移，也可以建立软链接，再将软链接放到/usr/inlcude 和/usr/lib64

这里采用第一种，结果如下

root@iZbp1inz4ol3gjahpjal9qZ:~/study# gcc -o main main.c -I lib/include
/usr/bin/ld: /tmp/ccGShNRL.o: in function `main':
main.c:(.text+0xe): undefined reference to `Print'
collect2: error: ld returned 1 exit status

报错显示找不到Print函数，属于链接报错。原因是你只告诉了.h的路径，并没有告诉.a文件的路径.
因此完整的命令如下
gcc main.c -o main -I ./lib/include/ -L ./lib/mylib -ltest
其中-L [库的路径]-l[库名]
注意库名要掐头去尾且最好与-l连在一起

root@iZbp1inz4ol3gjahpjal9qZ:~/study# tree lib
lib
├── include
│   └── test.h
└── mylib
    └── libtest.a

2 directories, 2 files
root@iZbp1inz4ol3gjahpjal9qZ:~/study# gcc -o main main.c -I lib/include -L lib/mylib -ltest
root@iZbp1inz4ol3gjahpjal9qZ:~/study# 

动态库

动态库：程序在运行的时候才去链接动态库的代码，多个程序共享使用库的代码。

linux下有个命令可以看到程序动态链接了哪些库 — ldd
以上文的main程序为例

（动态库的文件扩展名通常取为.so)

制作动态库

现在有两个文件：dytest.h, dytest.c，如下。

与制作静态库的流程一样，先生成目标文件，再打包。

执行上述命令后便会生成lib目录，libtest.so便是我们制作的动态库

使用动态库

创建main.c进行测试

同样和静态库一样：gcc main.c -o main -I ./lib/include/ -L ./lib/mylib/ -ltest
最后便会出现下面的错误

此时我们用ldd命令来查看，会看到not found,找不到库，可我们明明已经告诉编译器库在哪里，为什么还是找不到？原因是我们告诉了编译器，但现在已经是可执行程序，需要通过加载器来进行链接，但我们并没有告诉加载器，库在哪里。

解决这个问题的方法很多，这里介绍3种：

1. 安装到系统里，即/usr/lib64
2. 添加路径到环境变量LD_LTBRAY_PATH
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/sfw/study/3_10/lib/mylib
   地址写到库所在目录就可以了，因为库的名字早就写在可执行程序中
   但是这种方法，在重启时，环境变量更新，便会失效。除非，你写到系统配置文件里。
3. 在/etc/ld.so.conf.d里面建立动态库路径，然后ldconfig

/etc/ld.so.conf.d 目录是 Linux 下的动态链接器配置目录。在这个目录下，可以放置一系列以 .conf 结尾的文件，这些文件包含了动态链接器的库文件搜索路径配置。每个文件通常包含一组路径，告诉动态链接器在运行时去哪里搜索共享库文件。
操作如下：(下面操作需要root权限）

一般我们网上下载库，最常用的方法是直接安装到系统里。

动态库是如何被加载的

现在有两个可执行程序1.exe 2.exe.它们都链接了动态库dy.so。当程序运行时，dy.so会被加载到内存里，然后通过页表，映射到进程1和进程2的进程地址空间里的共享区。此时进程便可以正常执行。如下图。

小知识：
通过下图：我们知道多个进程是共用一个动态库。也就是下图物理内存中的红色区域。假设dy.so中有一个全局变量，假设为int errno = 0, 如果进程1中errno变为0了，那在进程2中errno的值会被为0吗？很显然不会，原因是发生了写时拷贝

这里还有一个小问题：
假设dy.so库里有一个函数 Print(), 在生成.so库的过程中，Print函数的虚拟地址是被硬编码到.so库里。这导致了一个问题，当进程使用Print(), dy.so首先被加载到物理内存里（加载到哪里不用关心）然后通过页表与虚拟地址相映射。但是由于Print函数的虚拟地址被硬编码到.so库，因此通过页表映射的Print函数虚拟地址是固定的。
那问题来了，这个虚拟地址已经被占了呢？那就出问题了。为了解决这个问题，动态库内的函数不在使用绝对地址，而是相对地址，即偏移量。

此时dy.so通过页表映射的虚拟地址不固定，之后要想找到Print函数，只需用dy.so的起始地址 + Print函数的偏移量。

回想前文：制作动态库的命令
gcc -fPIC -c test.c -o .test.o
-fPIC（Position Independent Code）是一个编译选项，主要用于在Linux上编译动态库时生成位置无关代码。它允许生成的代码在内存中的任意位置运行，而不依赖于固定的地址。
位置无关代码（PIC，Position Independent Code）是一种不依赖于内存中特定位置的代码。