我们在实际开发中，经常要使用别人已经实现好的功能，这是为了开发效率和鲁棒性（健壮性）；因为那些功能都是顶尖的工程师已经写好的，并且已经践行多年的代码。
那么如何使用他人开发的功能呢？
1.库: 包括静态库与动态库。
2.开源代码。
3.基本的网络功能调用，比如各种网络接口、语音识别等等。
这其中，我们将详细介绍静态库和动态库:
为什么在实际工作中一般将源码打包成动态静态库来给不同的人使用？
- 知识就是财富，你只是给某些人用一下你写的业务功能，并不想暴露源码的逻辑，那就打包成.obj目标文件甩给他用;
- 你也可以自己给自己封装库，因为你自己编译生成了.obj目标文件，是已经编译完成了的，只需要把这个库对应的头文件引入新的程序中,.obj文件放入库路径，这样新的程序链接器就可以直接把功能链接起来，方便部署使用，省去了反复编译的麻烦；
一般情况下，为了更好的支持开发，第三方库或者是语言库都必须提供静态库和动态库（eg:C C++等官方库），这是方便程序员根据需求功能进行可执行文件的生成;
动态链接使用动态库，而静态链接使用静态库。
一般来说，我们gcc编译默认是动态链接的而如果加上-static选项，那么生成的可执行文件将为静态生成;
底层优缺点
动态链接文件信息:
静态链接文件信息:
可以明显发现动态链接的文件大小明显要比静态链接的文件大小要小多了
这是因为动态链接是当程序执行到调用接口时，编译器再去特定路径查找目标接口的可执行文件,直接进行计算;
静态链接比较暴力，链接时候直接将目标接口的二进制代码全部链接到原文件中去，这也就是静态链接生成的文件这么大的原因了;（毕竟把二进制代码copy过来了）
但是这些都是相对的，有优点就有缺点:
万一动态库路径中的库丢失损坏 ，动态链接的程序到目标位置了，过来用的时候肯定出错了;
静态链接因为编译的时候吧二进制代码考过去了，不依赖原生库，即便原库代码丢失也没事;
小结
linux下库的命名格式一般为:
静态库: lib+库的名字+.a eg:c标准库为 libc.a
动态库: lib+库的名字+.so
静态库是指程序在编译链接的时候把库的二进制可执行代码链接到可执行文件中。程序运行的时候将不再需要静态库。
而动态库则是指程序在运行的时候才去启动指定位置的动态库的代码，使其加载到内存共享区中，多个程序共享使用库的二进制代码, 不用拉到本文件中来。
- 一个与动态库链接的可执行文件仅仅包含它用到的函数入口地址的一个表（头文件），而不是外部函数所在目标文件（.o）的整个机器码
- 在可执行文件开始运行以前，外部函数的机器码由操作系统从磁盘上的该动态库中复制到内存中，这个过程称为动态链接（dynamic linking），也就是说，动态链接是在需要调用接口时才会去将所用接口的二进制代码拷贝到内存中。
- 当一个库多文件使用时，动态库只有一份，所以可以在多个程序间共享，所以动态链接使得可执行文件更小，节省了磁盘空间。–>操作系统采用虚拟内存机制允许物理内存中的一份动态库被要用到该库的所有进程共用，节省了内存和磁盘空间。
- 这里需要提一下的是，我们之前所提过的进程地址空间中有一个共享区，而一般动态库的代码就映射在共享区，所有进程都共享着动态库的代码。
动态库被加载在内存中，可以供多个使用库的程序共享映射到自己的虚拟地址空间使用，因此可以减少页面交换以及降低内存中代码冗余，并且因为与源程序模块分离，因此开发模式比较好。
而加载动态库的程序运行速度相对较慢，因为动态库运行时加载，映射到虚拟地址空间后需要重新根据映射起始地址计算函数/变量地址。
静态库直接把二进制代码链接过来，与动态库的使用恰好相反，其运行速度相对较快，但消耗资源较多。
库函数源文件:
生成静态库需要先生成目标文件（.o）再进行打包，故先编写相应的源文件再将其编译成目标文件：
此时的add.o和sub.o文件是已经编译好但还没有链接的两个文件;
此时再用 ar命令,归档工具将其打包成静态库：
查看静态库
将库的头文件和静态库都放到指定lib目录下:
调用我们的库接口代码:
编译:
发现报错： 这是因为gcc编译时去链接库和头文件，是去默认路径以及当前源文件路径下寻找;
而我们将静态库打包到lib目录下，gcc编译时就找不到我们的库了，因此我们编译的时候，需要指定一些选项，并且带上路径https://www.jb51.net/article/lib;
因此，正确链接的指令为：
- -I(大写i) + 指定路径：告知gcc除了默认路径之外，还要去寻找这个指定路径的头文件。
- -L + 指定路径：除默认库路径以外，需要寻找这个指定路径的库
- -l（小写L）+ 库名称：表示要具体链接的是哪一个库;（因为路径下库可能不止一个）
- -static 选择使用静态库的静态链接
由此，我们就静态链接生成了一个可执行文件test，运行test程序结果如下：
此时我们删除静态库，发现照样可以运行，因为静态库中Add和Sub的二进制代码已经被链接入test程序中了，不怕原生库没了！
可见，有时候编译选项多而杂，难记，特别是文件一多，写的很麻烦，介绍一个camke构建项目的工具，C/C++开发人员必会技能;文章链接
类似与打包静态库使用的ar归档工具，动态库也有自己的语法，我们将生成动态库的依赖关系及方法写进自动化构建工具(Makefile)中：:
显然手动写Makefile和上面手动打包静态库一样，麻烦很多，我的评价是，直接cmake起飞;
注意:
- 由于动态库在内存中是可加载的，它可能在内存中的任意位置，也可能被映射到进程地址空间的每个区域，所以为了保证库当中的代码执行不会出错，也就是要保证库中的代码是与位置无关的，因此生成.o文件时需要带上-fPIC选项表示生成与位置无关码。
- 这里由于在依赖关系中已经点明了要生成的目标文件，故不带上$@也可以
- 打包动态库不是像静态库一样先gcc -o再使用ar（归档工具）;
- 而是用gcc 带上-shared选项表示生成共享动态库格式，这也体现了动态库代码映射在共享区的特点
编写好Makefile之后 make指令构建动态库 libmycal.so:
和静态库一样，我们把头文件和.so库文件放入lib目录，gcc的时候带上选项;
然后编译过了，运行程序时发现有问题,打不开动态库？:
既然编译都声称可执行程序了，此时的可执行程序是没问题的，因此已经与编译过程无关了;
那么这属于运行问题，其实运行时系统也会去默认路径下找到我们所使用的动态库，但在默认路径下没有我们的库。
这里解决方法有多种，但我倾向于推荐下面这一种：
修改环境变量,将动态库所在路径.lib添加到该环境变量中，这样程序在运行时系统就能够找到动态库，从而运行成功。
当然，还可以拷贝我们的.so文件到系统共享库路径下, 一般指/usr/lib;
但是这可能会污染系统原生的库，一般不推荐这样做。
还有一种方法，在我们的系统下有/etc/ld.so.conf.d/这个路径：
我们可以在这个路径下制造自己的.conf，然后再将自己的库路径写进这个conf中;
但是还是有点污染了原生库，不建议;
linux打包使用静态库:
接口的.c源文件–>.o目标二进制文件–>ar rc(归档工具)进行打包成.a静态库,编译程序使用时带上-static;(注意带上头文件寻找路径选项)
linux打包使用动态库:
接口的.c源文件–>.o目标二进制文件(需带上-fPIC 与位置无关)–>-shard 打包动态库;(注意带上头文件寻找路径选项)+(注意添加动态库寻找路径)
比如通过VS2019打包，由于是可视化界面方便操作，不再赘述，参考下方文章;
参考文章
到此这篇关于Linux下动静态库的打包与使用指南(C/C++)的文章就介绍到这了,更多相关Linux动静态库打包使用内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！
到此这篇动态库和静态库的优缺点（动态库和静态库的使用）的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章，希望大家都能在编程的领域有一番成就！版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/bcyy/31553.html