Linux软硬链接和动静态库(20)
文章目录
- 前言
- 一、软硬链接
- 基本认知
- 实现原理
- 应用场景
- 取消链接
- ACM时间
- 二、动静态库
- 认识库
- 库的作用
- 三、制作静态库
- 静态库的打包
- 静态库的使用
- 四、制作动态库
- 动态区的打包
- 动态库的链接与使用
- 动态库的链接原理
- 总结
前言
我有款非常喜欢玩的游戏，叫做《饥荒》，现在我下载了这一款游戏，但我不会跑到游戏所在目录中双击 .exe 打开游戏，大多数人都会通过桌面的快捷方式直接打开文件，而这个快捷方式实际就是对 .exe 的 软链接 文件； 当你在游戏中加载地图、道具等资源时，这些数据是存在 .exe 文件中的吗？ 答案是当然不是，这些资源文件都以 库 的方式与 .exe 位于同一目录中，通常为动态库，在 Windows 中后缀为 dll，那么这些神奇的辅助文件是如何产生的？ 其本质又是如何？本篇将带你一起揭晓。
另外还有一个小要求，请先回顾一下我上篇文章的 inode 这个概念，这在本篇仍很重要
一、软硬链接
基本认知
对文件进行软链接
ln -s file.txt file-soft.link
对文件进行硬链接
ln file.txt file-hard.link
源文件，软链接文件，硬链接文件如下：
注意： 可以对目录进行软链接，但不能对目录进行硬链接，具体原因后面再解释
那么生成的软硬链接有什么用呢？
像源文件一样使用即可，结果一模一样（因为当前软硬链接的都是同一个源文件）
同时我们发现这两种链接方式其本质上是有很大差别的：
- 软链接文件的 inode 编号与源文件不同（独立存在），软链接文件比源文件小得多，并且 软连接文件 -> 源文件
- 硬链接文件与源文件共用一个 inode 编号（对源文件其别名），硬链接文件与源文件一样大，并且硬链接文件与源文件的链接数变成了 2
软链接文件依赖于源文件，而硬链接文件是源文件的别名
当我们将源文件删除后，软链接失效； 硬链接仍然有效，不过硬链接数变为了 1
同样是对源文件进行链接，为何两种链接方式差别如此大呢？ 这就不得不谈一下它们的实现原理了
实现原理
软链接又称为符号链接，它是一个单独存在的文件，拥有属于自己的 inode 属性及相应的文件内容，不过在软链接的 Data block 中存放的是源文件的地址，因此软链接很小，并且非常依赖于源文件
在这里以QQ为例，可以看到快捷方式（软链接方式）中存放的是源文件的地址
因此如果源文件被删除了，那么在执行软连接文件时，其中的地址就是一个无效地址（目标文件已丢失），此时就会报错 No such file or directory
假设只是单纯的删除软连接文件，那么对源文件的内容没有丝毫影响，就好比 桌面上的快捷方式，有的人以为将快捷方式（软链接）文件删除了，就是在 “卸载” 软件，其实不是，如果想卸载软件，直接将其源文件相关文件夹全部删除即可
有多少人到现在还有误解呢？
硬链接并非创建一个相同的文件进行链接，而是在源文件所目录下的 （inode编号 & 文件名） 对应表中，新增 inode 编号与 硬链接文件名 的映射关系，并将 inode 结构体中的引用计数 +1，表示当前已成功硬链接上了一个文件
当删除当前 对应文件时，会 先判断 ref_count 是否为 1，如果是，才会将文件内容及其属性真正删除，否则删除的只是 文件名 与 inode 编号的映射关系inode
这也就解释了为什么删除源文件后，硬链接文件不受任何影响，仅仅只是 硬链接数 - 1，同理，删除硬链接文件，也不会影响源文件
为什么新建目录的硬链接数为 2 ？
- 因为一个目录在新建后，其中默认存在两个隐藏文件：. 与 …
- 其中 . 表示当前目录，… 表示上级目录
Linux 中的目录结构为多叉树，即当前节点（目录）需要与父节点（上级目录）、子节点（下级目录）建立链接关系，并且还得知道当前目录的地址，否则就会导致切换目录时出现错误
为了避免因用户的误操作而导致的目录环状问题，规定用户不能手动给目录建立硬链接关系，只能由 OS 自动建立硬链接，比如新目录后，默认与上级目录和当前目录建立硬链接文件，在当目录下创建新目录后，当前目录的硬链接数 + 1
所以说，将目录的硬链接数 - 2 ，得到的数字就是该目录下的目录数
4 - 2 = 2，所以目录 gitQuest 下一共有2个目录，我们来验证一下：
应用场景
软链接可以当作快捷方式使用，比如快速运行一个藏的很深的可执行程序
而硬链接一是可以用来当作目录移动的工具，二是可以用来给重要的源文件起别名并使用，一旦发生删除等不可逆行为时，可以确保源文件的安全
注意： 硬链接并不是将源文件直接进行备份，而是新建立 inode 编号与硬链接文件名的映射关系，同时 struct inode 中的引用计数 ref_count++，只有当 ref_count == 1 时才会真正删除文件内容及属性， 否则都只是在取消映射关系和 ref_count–
取消链接
取消链接的方式有两种：
- 直接删除链接文件
- 通过 unlink 取消链接关系
ACM时间
每一个文件都有三个时间：访问 Access、修改属性 Change、修改内容 Modify，简称为时间ACM
可以通过 查看指定文件的 时间信息 statACM
这三个时间的刷新策略如下：
- Access：最近一次查看内容的时间，具体实现取决于系统
- Change：最近一次修改属性的时间
- Modify：最近一次修改内容的时间（内容更改后，属性也会跟着修改）
Access 是高频操作，如果每次查看都更新的话，会导致 效率变低，因此 实际变化取决于刷新策略：查看 N 次后刷新IO
注意： 修改内容一定会导致属性时间被修改，但不一定会导致访问时间被修改，因为可以不打开文件，对文件进行操作
二、动静态库
认识库
常见的库文件：stdio.h stdlib.h string.h等
库分为 动态库 和 静态库
- Linux 中，.a 后缀为静态库，.so 后缀为动态库
- Windows 中，.lib 后缀为静态库，.dll 后缀为动态库
- 虽然不同环境下的后缀有所不同，但其工作原理是一致的
库命名
- 比如 libstdc++.so.6
- 去掉前缀跟后缀，最终库名为 stdc++
查找当前环境的库文件：
find /usr/lib64/libc*
C++ 中具体库文件可以这样查看：
find /usr/lib64/libstdc*
在编写程序时，一定离不开库文件，动态库优势比静态库明显，因此在编译代码时，默认采用动态链接的方式，如果想指定为静态链接编译，只需要在 gcc/g++ 语句后面加上 -static 即可（前提是得有静态库）
关于动静态库的优缺点可以看看下面这个表格
| 区别 | 动态库 | 静态库 |
|---|---|---|
| 调用方式 | 通过函数位置进行调用 | 直接将需要的函数拷贝至程序中 |
| 依赖性(运行时) | 需要依赖于动态库 | 可以独立于静态库运行 |
| 空间占用 | 共享动态库中的代码，空间占用少 | 拷贝代码会占用大量空间 |
| 加载速度 | 调用函数，加载速度慢 | 直接运行，加载速度快 |
注意： 静态库是将所需要的函数代码拷贝到源文件中直接使用，而动态库是通过动态链接的方式，进行函数链接使用，别急，这个我们后面会再细细讲解
库的作用
- 提高开发效率
- 头和库是有对应关系的，需要组合使用
- 头文件在预处理阶段就已经引入了，链接的本质就是在链接库
简言之，如果没有库文件，那么你在开发时，需要自己手动将 等高频函数编写出来，因此库文件可以提高我们的开发效率，比如 中就有很多现成的库函数可以使用，效率很高，如：printf
我们在IDE环境下编码的时候，语法提示是如何做到的？
- 安装开发环境，实际上是在安装编译器、开发语言配套的库和头文件
- 编译器的 语法提示功能来源于头文件（语法提示其实就是搜索）
我们在写代码时，开发环境是怎么知道语法错误或其他错误的？
- 编译器有命令行模式，还有其他自动化模式，编写代码时，不断进行主动编译，排查错误
三、制作静态库
现在有一些简单的计算 函数，能满足整型的 计算
主函数中将对这些自定义的库函数进行调用
静态库的打包
一共分为两步：
- 将源文件进行 预处理 -> 编译 -> 汇编，生成可链接的二进制 .o 文件
- 通过指令将 .o 文件打包为静态库
将文件编译为 .o 二进制文件
gcc -c add.c sub.c
将所有的 .o 文件打包为一个静态库（库名自定义），其中的 为库名mycalc
ar -rc libmycalc.a *.o
ar -tv 静态库文件
该指令可以查看打包的库文件
获得静态库后，就可以进行使用了
静态库的使用
方法一：通过指定路径使用静态库
如果直接编译程序，会出现编译失败的情况，因为编译器不认识第三方库（需要提供第三方库的路径及库名）
第一方库：语言提供
第二方库：操作系统提供
第三方库：other 提供的库，比如当前我们直接打包的静态库
对于自己写的的第三库的使用，需要标注三个参数：
- -I 所需头文件的路径 需要将所需头文件的路径加上，此处为 ./stdc/include
- -L 所需库文件的路径 这里加的是库文件的路径，也为 ./stdc/lib
- -l 待链接静态库名 所需要链接的静态库名字，这里为 libmycalc.a
将选项加上后重新编译
方块二：将头文件和静态库文件安装至系统目录中
除了这种比较麻烦的指定路径编译外，我们还可以将头文件与静态库文件直接安装在系统目录中，直接使用，无需指定路径（需要指定静态库名）
所谓的安装软件，就是将自己的文件安装到系统目录下
sudo cp ./stdc/include/*.h /usr/include/
sudo cp ./stdc/lib/*.a /lib64/
注意： 将自己写的文件安装到系统目录下是一件危险的事（导致系统环境被污染），用完后记得手动删除
四、制作动态库
动态区的打包
动态库不同于静态库，动态库中的函数代码不需要加载到源文件中，而是通过 与位置无关码 ，对指定函数进行链接使用
动态库的打包也同样分为两步：
- 编译源文件，生成二进制可链接文件，此时需要加上 -fPIC 与位置无关码
- 通过 gcc/g++ 直接目标程序（此时不需要使用 ar 归档工具）
将源文件编译为 .o 二进制文件，此时需要带上 fPIC 与位置无关码
将所有的 .o 文件打包为动态库（借助 gcc/g++）
gcc -o libmycalc.so *.o -shared
获得动态库后，就可以进行使用了
动态库的链接与使用
像使用静态库一样使用动态库（指定路径及库名），编译成功，但运行失败！
为什么会出现这种问题？ 因为当前只告诉了编译器动态库的位置，没有告诉 OS
通过 查看程序链接情况：ldd
运行时， 是如何链接动态库？OS
- 环境变量 LD_LIBRARY_PATH （默认没有这个环境变量），将第三方动态库路径添加至此环境变量中（临时方案）
- sudo 在 /lib64/ 目录下建立动态库的软链接
- 更改配置文件 /etc/ld.so.conf.d 这个目录中都是各种动态库配置文件，创建文件 xx.conf 至目录中（文件中存储的是第三方动态库的路径）ldconfig 令配置文件生效
方法一：通过环境变量解决
添加动态库路径至 环境变量中LD_LIBRARY_PATH
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:路径
环境变量 是程序在进行动态库查找时的默认搜索路径LD_LIBRARY_PATH
注意： 更改环境变量只是临时方案，重新登录后会失效
方法二：将动态库的软链接文件存入系统目录中
sudo ln -s 路径 /lib64/libmycalc.so
注意： 创建软连接文件时，需要使用绝对路径！
方法三：更改配置文件中的信息
echo 路径 > lhq.conf
sudo mv lhq.conf /etc/ld.so.conf.d/
sudo ldconfig # 手动更新
注意： 后两种方法都可以做到永久生效（因为存入了系统目录中），但在使用完后最好删除，避免污染系统环境
动态库的链接原理
程序在链接动态库函数时，是通过 动态库起始地址 + 所链接函数偏移量 的方式进行链接访问的，而这个偏移量就是 fPIC 与位置无关码
地址其实就两种：绝对地址和相对地址，静态链接时，将可链接的二进制文件加载至程序中，直接通过 绝对地址 进行链接，假设函数被调用了多次，就会导致代码冗余等问题； 动态链接采用 相对地址 的方式进行链接，同一个函数的 + 值相同，代码只需要加载一份，并且可以任意位置进行函数调用（与位置无关）动态库起始地址所链接函数偏移量
动态库中所有地址都是偏移量，默认从 开始0
只有当一个库被真正映射进地址空间后，它的起始地址才能真正确定
- 链接库中的函数时，通过 动态库的起始地址 + 函数偏移量 的方式链接函数
- 这种方法不论在什么位置，都可以随便链接函数（与位置无关）
- 与位置无关码：动态库中地址，是偏移量
总结
最后还有需要总结的一些要点就是：
- 当同时拥有 静态库 和 动态库 时，默认采用动态链接
- 可以在编译的时候最后加上 -static 指定 静态链接
- 只有静态库，又不指定静态链接，这个时候是动态链接（内含静态库）
- 静态链接生成的程序比动态链接大得多，并且内含静态库的动态链接程序，也比纯粹的动态链接程序大，程序并非非静即动
另外，你可不可以利用 Makefile 来简化步骤？