Linux下库函数、静态库与动态库
库函数
什么是库
库是二进制文件, 是源代码文件的另一种表现形式, 是加了密的源代码;
是一些功能相近或者是相似的函数的集合体.
使用库有什么好处
- 提高代码的可重用性, 而且还可以提高程序的健壮性;
- 可以减少开发者的代码开发量, 缩短开发周期.
库制作完成后, 如何给用户使用
- 头文件---包含了库函数的声明
- 库文件---包含了库函数的代码实现
注意: 库不能单独使用, 只能作为其他执行程序的一部分完成某些功能, 也
就是说只能被其他程序调用才能使用.
库可分静态库(static library)和共享库(shared library)
代码：
静态库
静态库可以认为是一些目标代码的集合, 是在可执行程序运行前就已经加入到执行码中, 成为执行程序的一部分. 按照习惯, 一般以.a做为文件后缀名.
静态库的命名一般分为三个部分：
- 前缀：lib
- 库名称：自定义即可, 如test
- 后缀：.a
所以最终的静态库的名字应该为：libtest.a
静态库的制作
下面以fun1.c , fun2.c和head.h三个文件为例讲述静态库的制作和使用, 其中head.h文件中有函数的声明, fun1.c和fun2.c中有函数的实现.
步骤1：将c源文件生成对应的.o文件
gcc -c fun1.c fun2.c
或者分别生成.o文件:
gcc -c fun1.c -o fun1.o
gcc -c fun2.c -o fun2.o
步骤2：使用打包工具ar将准备好的.o文件打包为.a文件
- 在使用ar工具是时候需要添加参数rcs
- r更新、c创建、s建立索引
- 命令：ar rcs 静态库名 .o文件
- ar rcs libtest1.a fun1.o fun2.o
静态库的使用
静态库制作完成之后, 需要将.a文件和头文件一定发布给用户.
假设测试文件为main.c, 静态库文件为libtest1.a, 头文件为head.h
用到的参数：
- -L：指定要连接的库的所在目录
- -l：指定链接时需要的静态库, 去掉前缀和后缀(这是小写L)
- -I: 指定main.c文件用到的头文件head.h所在的路径（这是大写i）
gcc -o main1 main.c -L./ -ltest1 -I./
静态库的优缺点
-
优点：
- 函数库最终被打包到应用程序中，实现是函数本地化，寻址方便、速度快。
（库函数调用效率==自定义函数使用效率）
-
- 程序在运行时与函数库再无瓜葛，移植方便。
-
缺点：
- 消耗系统资源较大, 每个进程使用静态库都要复制一份, 无端浪费内存。
-
- 静态库会给程序的更新、部署和发布带来麻烦。如果静态库libxxx.a更新了，所有使用它的应用程序都需要重新编译、发布给用户（对于玩家来说，可能是一个很小的改动，却导致整个程序重新下载）。
代码：
动态库
共享库在程序编译时并不会被连接到目标代码中, 而是在程序运行是才被载入. 不同的应用程序如果调用相同的库, 那么在内存里只需要有一份该共享库的拷贝, 规避了空间浪费问题.动态库在程序运行时才被载入, 也解决了静态库对程序的更新、部署和发布会带来麻烦. 用户只需要更新动态库即可, 增量更新. 为什么需要动态库, 其实也是静态库的特点导致.
按照习惯, 一般以”.so”做为文件后缀名. 共享库的命名一般分为三个部分：
- 前缀：lib
- 库名称：自己定义即可, 如test
- 后缀：.so
所以最终的静态库的名字应该为：libtest.so
共享库的制作
- 生成目标文件.o, 此时要加编译选项：-fPIC（fpic）
gcc -fpic -c fun1.c fun2.c
参数：-fpic创建与地址无关的编译程序(pic, position independent code), 目的就是为了能够在多个应用程序间共享.
- 生成共享库, 此时要加链接器选项: -shared（指定生成动态链接库）
gcc -shared fun1.o fun2.o -o libtest2.so
共享库的使用
引用动态库编译成可执行文件（跟静态库方式一样）：
用到的参数：
- -L：指定要连接的库的所在目录
- -l：指定链接时需要的动态库, 去掉前缀和后缀
- -I: 指定main.c文件用到的头文件head.h所在的路径
gcc main.c -I./ -L./ -ltest2 -o main2
然后运行：./main2，发现竟然报错了.
分析为什么在执行的时候找不到libtest2.so库
- 当系统加载可执行代码时候, 能够知道其所依赖的库的名字, 但是还需要知道所依赖的库的绝对路径。此时就需要系统动态载入器(dynamic linker/loader)。
ldd命令可以查看可执行文件依赖的库文件, 执行ldd main2, 可以发现libtest2.so找不到.
- 对于elf格式的可执行程序，是由ld-linux.so*来完成的, 它先后搜索elf文件的 DT_RPATH段 — 环境变量LD_LIBRARY_PATH — /etc/ld.so.cache文件列表 — /lib/, /usr/lib目录找到库文件后将其载入内存。
使用file命令可以查看文件的类型: file main2
如何让系统找到共享库
- 拷贝自己制作的共享库到/lib或者/usr/lib
- 临时设置LD_LIBRARY_PATH:
- export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:库路径
- 永久设置, 把export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:库路径, 设置到∼/.bashrc文件中, 然后在执行下列三种办法之一:
- 执行. ~/.bashrc使配置文件生效(第一个.后面有一个空格)
- 执行source ~/.bashrc配置文件生效
- 退出当前终端, 然后再次登陆也可以使配置文件生效
- 永久设置,把export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:库路径，设置到/etc/profile文件中
- 将其添加到 /etc/ld.so.cache文件中
- 编辑/etc/ld.so.conf文件, 加入库文件所在目录的路径
- 运行sudo ldconfig -v, 该命令会重建/etc/ld.so.cache文件
解决了库的路径问题之后, 再次ldd命令可以查看可执行文件依赖的库文件, ldd main2:
共享库的特点
- 动态库把对一些库函数的链接载入推迟到程序运行的时期。
- 可以实现进程之间的资源共享。（因此动态库也称为共享库）
- 将一些程序升级变得简单。
- 甚至可以真正做到链接载入完全由程序员在程序代码中控制（显示调用）
代码：
文件夹所属情况：
修改动态库的路径：
改完之后一切按步骤进行即可！
我设置的是工作文件中的lib，而不是用户目录下的lib
那为啥要将库函数打包了？
我gcc add.c main.c -o main不照样可以执行？
将库函数打包成库的主要目的之一是为了代码的重用。当您有多个程序需要使用相同的函数或者模块时，将这些函数或模块打包成库可以节省时间和精力，并提高代码的可维护性。库函数可以被多个程序共享，而不需要每个程序都重新编写一遍。
另一个重要的原因是为了减少可执行文件的大小。如果您使用静态库，编译器会将库函数的代码和数据嵌入到可执行文件中，这会增加可执行文件的大小。而如果使用动态库，可执行文件只包含对动态库的引用，因此可执行文件的大小会更小。这对于大型项目或需要频繁分发的程序来说尤为重要。
库函数与静态库、动态库的关系：
将add.o和sub.o打包成静态库后，就是将文件中的数据复制到静态库文件中
静态库
在创建静态库时，这些目标文件会被归档到静态库中，使得静态库中包含了这些目标文件中的所有代码和数据。这样，当链接器在编译时将静态库链接到可执行文件时，它会从静态库中提取所需的代码和数据，然后将其合并到最终的可执行文件中。
动态库
动态库与静态库类似，也包含了代码和数据，但与静态库不同的是，动态库在运行时由动态链接器加载到内存中。因此，动态库文件中包含了一些额外的信息，以支持动态链接器在运行时正确地加载和链接动态库。
动态库文件的格式通常比较复杂，包含了符号表、重定位表、动态链接信息等。这些信息使得动态链接器能够在程序运行时正确地加载和链接动态库，并且支持库的版本管理和符号重定位等功能。