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.a

int 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.out
	linux-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)

失败的样子

9.那么这里又有一个问题了，当我们给了user  .h文件和  .so文件后，还要教客户怎么在 配置吗？

实际开发中怎么做的呢？