125 Linux C++ 系统编程4 Linux 静态库制作，动态库制作，静态库和动态库对比。静态库运行时找不到库的bug fix

一静态库和动态库对比

静态库的原理：假设我们有一个静态库，大小为500M，这个静态库实现了一些打牌的逻辑算法，提供了一堆API，让开发者可以轻松的实现 54张扑克牌的随机发牌，指定发牌等功能。

我们写了一个腾讯的棋牌类游戏，在牌类中，有斗地主，够级，升级等游戏，很显然，每一个单独的游戏都是一个可执行的 .out文件了。

假设叫做 a.out,b.out,c.out

显然这a.out,. b.out,c.out都会用到静态库中的这些方法。

那么静态库和每一个 .out结合的样子，类似下图：

也就是说：

静态库会被每个.out copy 一份到自己的代码里面。

静态库要求执行效率高，但是会牺牲空间。

操作系统的开机加载的一般都是静态库。

目前静态库的应用比较少，动态库的场景比较多，静态库知道怎么弄，如果今后开发中遇到了，知道怎么实做就可以了。

静态库在应用程序生成后，可以不必再编译，节省再编译时间，如果其他开发人员要使用您的程序，而你又不想给其源码，提供静态库是一种选择。

动态库则不会被copy

动态库会单独的存放一份，被大家共享，不会被各个 .out文件copy 一份。而是在a.out需要的时候去动态库中找到想要的 api，调用一下。

二如果制作一个静态库

1.使用写好的 .c.h.cpp文件生成.o文件

g++ -c addfunc.cpp -I ./head -o addfunc.o
g++ -c subfunc.cpp -I ./head -o subfunc.o
g++ -c mulfunc.cpp -I ./head -o mulfunc.o
g++ -c devfunc.cpp -I ./head -o devfunc.o

2.build 出来静态库文件，我们这里起名叫做 libdou.a

ar rcs libdou.a addfunc.o subfunc.o mulfunc.o devfunc.o

这时候我们就得到了 libdou.a

关于1,2的说明

在build 出来静态库之前，是需要生成所有.c 和 .cpp的.o文件的，我们这里将.h文件都放在了head头文件里面

我们使用的代码如下：有5个文件，一个.h 放在 head文件夹下，4个.cpp文件

dou.h
#pragma once
#include <iostream>
using namespace std;
//目前的状况是：我们是第三方的库开发者，致力于开发一些第三方库卖钱，开发了一个加减乘除的算法库，
//这个算法很先进，使用了AI技术，是8个博士后的心血结晶，我们不希望使用者知道开发的细节，
//因此我们需要提供一个 .h文件，告知使用者你要引入的头文件是这个.h文件
//并且提供了一个静态库给 开发者，libdou.aint addfunc01(int a, int b);
int subfunc02(int a, int b);
int mulfunc03(int a, int b);
int devfunc04(int a, int b);

addfunc.cpp
#include "dou.h"int addfunc01(int a, int b) {return a + b;
}

subfunc.cpp
#include "dou.h"int subfunc02(int a, int b) {return a - b;
}

mulfunc.cpp#include "dou.h"int mulfunc03(int a, int b) {return a * b;
}

devfunc.cpp#include "dou.h"int devfunc04(int a, int b) {if (b == 0) {cout << "devfunc04 error because dividend ==0" << endl;return -1;}return a / b;
}

g++ -c addfunc.cpp -I ./head -o addfunc.o
g++ -c subfunc.cpp -I ./head -o subfunc.o
g++ -c mulfunc.cpp -I ./head -o mulfunc.o
g++ -c devfunc.cpp -I ./head -o devfunc.o
ar rcs libdou.a addfunc.o subfunc.o mulfunc.o devfunc.o

这时候我们就得到了 libdou.a

3. 第三方公司如何应用

3.0我们卖给第三方公司的就是一个头文件dou.h，和一个libdou.a,

3.1 第三方的有一个 test.cpp,在这个 test.cpp 用到了静态库中的一些方法

需要导入我们的 #include "dou.h"

并且将dou.h 放在和test.cpp 一行的 head目录下

test.cpp
#include <iostream>
#include "dou.h"
using namespace std;int main(){cout<<"a+b = " << addfunc01(10,5)<<endl;cout<<"a-b = " << subfunc02(10,5)<<endl;cout<<"a*b = " << mulfunc03(10,5)<<endl;cout<<"a/b = " << devfunc04(10,5)<<endl;return 0;
}

3.2 将test.cpp 和静态库文件 libdou.a 静态编译在一起。生出来一个test.out文件

g++ test.cpp libdou.a -o test.out -I ./head

3.3执行 ./test.out

hunandede@hunandede-virtual-machine:~/day02/staticlib$ g++ test.cpp libdou.a -o test.out -I ./head
hunandede@hunandede-virtual-machine:~/day02/staticlib$ ./test.out
a+b = 15
a-b = 5
a*b = 50
a/b = 2

3.4 查看 test.out的大小

我们观察到最终客户生成的 test.out 占据的大小为 14016，但是实际上我们的test.cpp文件只有269这么大。可见确实将静态库 build 自己里面了。

三 .动态库的制作和使用

1.使用写好的 .c.h.cpp文件生成.o文件

但是这种动态库的.o文件，是和静态库的.o文件不一样。因此制作方法也不一样。

动态库制作.o文件的方法：

g++ -c addfunc.cpp -I ./head -o addfunc.o -fPIC

静态库制作.o文件的方法：

g++ -c addfunc.cpp -I ./head -o addfunc.o

g++ -c addfunc.cpp -I ./head -o addfuncdongtai.o -fPIC
g++ -c subfunc.cpp -I ./head -o subfuncdongtai.o -fPIC
g++ -c mulfunc.cpp -I ./head -o mulfuncdongtai.o -fPIC
g++ -c devfunc.cpp -I ./head -o devfuncdongtai.o -fPIC

如下是两者不同原理性的说明：能看懂就看，看不懂拉倒.记住前面的结论就可以了

静态库中方法的地址是以main为依据，一般都是main的地址+xxx

例如我们的 addfunc01方法的地址就是 main的地址+100，（注意，这里100不是一个真实的值，是我们猜测的）

在编译的第四阶段，链接的时候，会将main的地址给定一个确定的值，因此我们调用addfunc01的时候，地址也就确定了

动态库的方法的地址不是以main为依据的，只有在调用到 addfunc01dongtai 方法的时候，才去找真实的地址，因此也叫做动态绑定，查看printf函数的反汇编，会有 <printf@plt>的字样，知道这里就可以了。

2,。使用 g++ -shared 制作动态库

gcc -shared -o lib库名.so add.o sub.o div.o

使用参数 -shard

-o 重命名

lib库名.so 为我们要制作出来的动态库文件

g++ -shared -o libdoudongtai.so addfuncdongtai.o subfuncdongtai.o mulfuncdongtai.o devfuncdongtai.o

3.编译可执行程序时，指定所使用的动态库，-l ：指定库名 -L：指定库路径

g++ test.cpp -o a.out -lmymath -L./lib

注意我们实现的时候并没有将libdoudongtai.so放在 lib目录下，而是和test.cpp放在一起了，只是将将.h文件放在 head文件夹下。

 g++ test.cpp -o a.out -ldoudongtai -L./ -I./head

4.运行可执行程序发生问题

./a.out

./a.out: error while loading shared libraries: libdoudongtai.so: cannot open shared object file: No such file or directory

5.动态库运行原理以及 bug fix

原因：动态库想要执行需要两个关键的地方：链接器和动态链接器

链接器和动态链接器没有关系，可以理解为 “张三” 和 “张三丰” 的关系。

链接器：工作于编译的链接阶段，工作时需要 -l 和 -L 支持，我们已经在前面说明了在哪里

动态链接器：工作于程序运行阶段，工作时需要提供动态库所在目录位置。

动态库所在目录位置是几个比较固定的位置，我们需要将动态库所在目录放在这几个固定的位置，如下的说明，应该是有三个地方


当执行函数动态链接.so时，如果此文件不在缺省目录下‘/lib’ and ‘/usr/lib’.那么就需要指定环境变量LD_LIBRARY_PATH

1.动态环境变量存放的地方：为 LD_LIBRARY_PATH

export 表示导入，下面的意思是，导入LD_LIBRARY_PATH为当前文件夹。

export LD_LIBRARY_PATH=./

然后执行 ./a.out 结果正常

2. 当我们将当前的窗口关闭，然后重新打开一个窗口的时候，cd到当前目录，执行 ./a.out 又无法执行了，这是因为 LD_LIBRARY_PATH 环境变量是进程的概念，我们刚才打开的窗口中执行了 export LD_LIBRARY_PATH=./ 当这个窗口关闭后，设置的也就不生效了。

那么怎么弄呢？既然窗口关闭后，LD_LIBRARY_PATH 环境变量的值就会使用默认的，那么我们就改动窗口的配置即可。从前几章的知识我们知道，我们在窗口打的字，最终是 shell 解释器在处理内容，然后回复给我们，shell有很多种，而在unbutu中，这个shell 实际上 bash。因此我们改动bash的配置文件就OK了。bash的配置文件叫做 .bashrc

打开 .bashrc ，添加 export LD_LIBRARY_PATH=./

注意后面的./ 是路径，如果我们这么加，每次都需要进入到 a.out的目录才能执行a.out

建议改成绝对路径，打开 .bashrc ，添加 export LD_LIBRARY_PATH=/home/hunandede/day02/dongtaiku/

总结

上面写的太多了。整理

5.1 临时生效方法，只在当前窗口有用

export 表示导入，下面的意思是，导入LD_LIBRARY_PATH为当前文件夹。

export LD_LIBRARY_PATH=./

5.2 永久生效的方法：配置bash的配置文件 .bashrc

1.打开终端，vim ~/.bashrc

2.在最后一行加上

export LD_LIBRARY_PATH=/home/hunandede/day02/dongtailib

保存，退出

3 执行 . .bashrc/ 重启终端 (这个好像不行，先不管)

或者 source .bashrc 重启终端

或者关闭终端后，重新打开

4.执行 ./a.out

6.动态库bug fix2 ，加入到 ‘/lib’ 或者‘/usr/lib’ 中

当执行函数动态链接.so时，如果此文件不在缺省目录下‘/lib’ and ‘/usr/lib’.

才会去找 LD_LIBRARY_PATH

因此我们也可以将 .so文件copy 一份放在根目录下的 /lib文件下。

7.动态库 bug fix3，配置文件方法-- 修改etc/ld.so.conf

1.修改etc/ld.so.conf

sudo vim /etc/ld.so.conf

添加你的共享库路径

2.更新查找共享库的路径 -v 是显示个用户看过程的意思

sudo ldconfig -v

3.测试你的程序可否找到共享库

ldd a.out

8.怎么知道 a.out 文件是否已经有所有的动态库了呢？

可以使用 ldd a.out 查看

ldd 是这个命令，它会分析 a.out执行起来需要哪些动态库，以及这些动态库执行起来的路径在哪里，如果你的动态库缺失，或者没有配置，则后面为空

如下：我们的 a.out是OK的，因此查看

hunandede@hunandede-virtual-machine:~/day02/dongtailib$ ldd a.outlinux-vdso.so.1 =>  (0x00007ffe28528000)libdoudongtai.so => /home/hunandede/day02/dongtailib/libdoudongtai.so (0x00007fb421ae1000)libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fb42175f000)libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb421395000)libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb42108c000)/lib64/ld-linux-x86-64.so.2 (0x00007fb421ce4000)libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fb420e76000)

失败的样子