Linux下动静态库的打包与使用C C++
目录 Linux下的动静态库 打包静态库 打包动态库 小结win下打包动静态库
前言 为什么用动静态库
我们在实际开发中，经常要使用别人已经实现好的功能，这是为了开发效率和鲁棒性（健壮性）；因为那些功能都是顶尖的工程师已经写好的，并且已经践行多年的代码。
那么如何使用他人开发的功能呢？
1.库: 包括静态库与动态库。
2.开源代码。
3.基本的网络功能调用，比如各种网络接口、语音识别等等。
这其中，我们将详细介绍静态库和动态库:
为什么在实际工作中一般将源码打包成动态静态库来给不同的人使用？
知识就是财富，你只是给某些人用一下你写的业务功能，并不想暴露源码的逻辑，那就打包成.obj目标文件甩给他用;你也可以自己给自己封装库，因为你自己编译生成了.obj目标文件，是已经编译完成了的，只需要把这个库对应的头文件引入新的程序中,.obj文件放入库路径，这样新的程序链接器就可以直接把功能链接起来，方便部署使用，省去了反复编译的麻烦； 动态链接与静态链接
一般情况下，为了更好的支持开发，第三方库或者是语言库都必须提供静态库和动态库（eg:C C++等官方库），这是方便程序员根据需求功能进行可执行文件的生成;
动态链接使用动态库，而静态链接使用静态库。
一般来说，我们gcc编译默认是动态链接的而如果加上-选项，那么生成的可执行文件将为静态生成;
底层优缺点
动态链接文件信息:
静态链接文件信息:
可以明显发现动态链接的文件大小明显要比静态链接的文件大小要小多了
这是因为动态链接是当程序执行到调用接口时，编译器再去特定路径查找目标接口的可执行文件,直接进行计算;
静态链接比较暴力，链接时候直接将目标接口的二进制代码全部链接到原文件中去，这也就是静态链接生成的文件这么大的原因了;（毕竟把二进制代码copy过来了）
但是这些都是相对的，有优点就有缺点:
万一动态库路径中的库丢失损坏 ，动态链接的程序到目标位置了，过来用的时候肯定出错了;
静态链接因为编译的时候吧二进制代码考过去了，不依赖原生库，即便原库代码丢失也没事;
小结
Linux下的动静态库
linux下库的命名格式一般为:
静态库: lib+库的名字+.a eg:c标准库为 libc.a
动态库: lib+库的名字+.so
静态库是指程序在编译链接的时候把库的二进制可执行代码链接到可执行文件中。程序运行的时候将不再需要静态库。
而动态库则是指程序在运行的时候才去启动指定位置的动态库的代码，使其加载到内存共享区中，多个程序共享使用库的二进制代码, 不用拉到本文件中来。
动静态库的对比
动态库被加载在内存中，可以供多个使用库的程序共享映射到自己的虚拟地址空间使用，因此可以减少页面交换以及降低内存中代码冗余，并且因为与源程序模块分离，因此开发模式比较好。
而加载动态库的程序运行速度相对较慢，因为动态库运行时加载，映射到虚拟地址空间后需要重新根据映射起始地址计算函数/变量地址。
静态库直接把二进制代码链接过来，与动态库的使用恰好相反，其运行速度相对较快，但消耗资源较多。
打包静态库
库函数源文件:
//file1: Add.c
#include生成静态库需要先生成目标文件（.o）再进行打包，故先编写相应的源文件再将其编译成目标文件：
//生成两个二进制目标文件
[root@VM-8-15-centos fighting]# gcc -c Sub.c -o Sub.o
[root@VM-8-15-centos fighting]# gcc -c Add.c -o Add.o
此时的add.o和sub.o文件是已经编译好但还没有链接的两个文件;
此时再用 ar命令,归档工具将其打包成静态库：
//将这俩二进制目标文件打包成静态库
[lyl@VM-4-3-centos 2022-3-14]$ ar -rc libmycal.a Add.o Sub.o //`rc`表示(replace and create)
查看静态库
//查看静态库的目录列表
[root@VM-8-15-centos fighting]# ar -tv libmycal.a `tv`表示(列出静态库中文件 and verbose详细信息)
rw-r--r-- 0/0 936 Jan 24 16:57 2023 Add.o
rw-r--r-- 0/0 1240 Jan 24 16:57 2023 Sub.o
使用静态库
将库的头文件和静态库都放到指定lib目录下:
调用我们的库接口代码:
#include 编译:
发现报错： 这是因为gcc编译时去链接库和头文件，是去默认路径以及当前源文件路径下寻找;
//gcc 寻找的默认头文件路径:不建议污染原生库
/usr/include
//gcc 寻找的默认库文件路径:
/lib , lib64 ......等
而我们将静态库打包到lib目录下，gcc编译时就找不到我们的库了，因此我们编译的时候，需要指定一些选项，并且带上路径./lib;
因此，正确链接的指令为：
gcc -o test test.c -I ./lib -L ./lib -lmycal -static
由此，我们就静态链接生成了一个可执行文件test，运行test程序结果如下：
此时我们删除静态库，发现照样可以运行，因为静态库中Add和Sub的二进制代码已经被链接入test程序中了，不怕原生库没了！
可见，有时候编译选项多而杂，难记，特别是文件一多，写的很麻烦，介绍一个camke构建项目的工具，C/C++开发人员必会技能;博客链接
打包动态库
类似与打包静态库使用的ar归档工具，动态库也有自己的语法，我们将生成动态库的依赖关系及方法写进自动化构建工具()中：:
显然手动写和上面手动打包静态库一样，麻烦很多，我的评价是，直接cmake起飞;
注意:
编写好之后 make指令构建动态库 .so:
使用动态库
和静态库一样，我们把头文件和.so库文件放入lib目录，gcc的时候带上选项;
gcc -o test test.c -I ./lib -L ./lib -l mycal //因为是动态链接 所以不用带-static了
然后编译过了，运行程序时发现有问题,打不开动态库？:
既然编译都声称可执行程序了，此时的可执行程序是没问题的，因此已经与编译过程无关了;
那么这属于运行问题，其实运行时系统也会去默认路径下找到我们所使用的动态库，但在默认路径下没有我们的库。
这里解决方法有多种，但我倾向于推荐下面这一种：
修改环境变量,将动态库所在路径.lib添加到该环境变量中，这样程序在运行时系统就能够找到动态库，从而运行成功。
当然，还可以拷贝我们的.so文件到系统共享库路径下, 一般指/usr/lib;
但是这可能会污染系统原生的库，一般不推荐这样做。
还有一种方法，在我们的系统下有**/etc/ld.so.conf.d/**这个路径：
我们可以在这个路径下制造自己的.conf，然后再将自己的库路径写进这个conf中;
但是还是有点污染了原生库，不建议;
小结
linux打包使用静态库:
接口的.c源文件–>.o目标二进制文件–>ar rc(归档工具)进行打包成.a静态库,编译程序使用时带上-;(注意带上头文件寻找路径选项)
linux打包使用动态库:
接口的.c源文件–>.o目标二进制文件(需带上-fPIC 与位置无关)–>-shard 打包动态库;(注意带上头文件寻找路径选项)+(注意添加动态库寻找路径)
win下打包动静态库
比如通过打包，由于是可视化界面方便操作，不再赘述，参考下方文章;
参考文章
