一 静态库 和动态库 对比
静态库的原理：假设我们有一个 静态库，大小为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.o2.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./head4.运行 可执行程序 发生问题
./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文件后，还要教客户怎么在 配置吗？
实际开发中怎么做的呢？
