---

前言

  我有款非常喜欢玩的游戏，叫做《饥荒》，现在我下载了这一款游戏，但我不会跑到游戏所在目录中双击 .exe 打开游戏，大多数人都会通过桌面的快捷方式直接打开文件，而这个快捷方式实际就是对 .exe 的 软链接 文件； 当你在游戏中加载地图、道具等资源时，这些数据是存在 .exe 文件中的吗？ 答案是当然不是，这些资源文件都以 库 的方式与 .exe 位于同一目录中，通常为动态库，在 Windows 中后缀为 dll，那么这些神奇的辅助文件是如何产生的？ 其本质又是如何？本篇将带你一起揭晓。

另外还有一个小要求，请先回顾一下我上篇文章的 inode 这个概念，这在本篇仍很重要

---

一、软硬链接

基本认知

对文件进行软链接

ln -s file.txt file-soft.link

对文件进行硬链接

ln file.txt file-hard.link

源文件，软链接文件，硬链接文件如下：

注意： 可以对目录进行软链接，但不能对目录进行硬链接，具体原因后面再解释

  那么生成的软硬链接有什么用呢？

  像源文件一样使用即可，结果一模一样（因为当前软硬链接的都是同一个源文件）

同时我们发现这两种链接方式其本质上是有很大差别的：

1. 软链接文件的 inode 编号与源文件不同（独立存在），软链接文件比源文件小得多，并且 软连接文件 -> 源文件
2. 硬链接文件与源文件共用一个 inode 编号（对源文件其别名），硬链接文件与源文件一样大，并且硬链接文件与源文件的链接数变成了 2

软链接文件依赖于源文件，而硬链接文件是源文件的别名

当我们将源文件删除后，软链接失效； 硬链接仍然有效，不过硬链接数变为了 1

  同样是对源文件进行链接，为何两种链接方式差别如此大呢？ 这就不得不谈一下它们的实现原理了

实现原理

  软链接又称为符号链接，它是一个单独存在的文件，拥有属于自己的 inode 属性及相应的文件内容，不过在软链接的 Data block 中存放的是源文件的地址，因此软链接很小，并且非常依赖于源文件

  在这里以QQ为例，可以看到快捷方式（软链接方式）中存放的是源文件的地址

  因此如果源文件被删除了，那么在执行软连接文件时，其中的地址就是一个无效地址（目标文件已丢失），此时就会报错 No such file or directory

  假设只是单纯的删除软连接文件，那么对源文件的内容没有丝毫影响，就好比 桌面上的快捷方式，有的人以为将快捷方式（软链接）文件删除了，就是在 “卸载” 软件，其实不是，如果想卸载软件，直接将其源文件相关文件夹全部删除即可

有多少人到现在还有误解呢？

  硬链接并非创建一个相同的文件进行链接，而是在源文件所目录下的 （inode编号 & 文件名） 对应表中，新增 inode 编号与 硬链接文件名 的映射关系，并将 inode 结构体中的引用计数 +1，表示当前已成功硬链接上了一个文件

  当删除当前 对应文件时，会 先判断 ref_count 是否为 1，如果是，才会将文件内容及其属性真正删除，否则删除的只是 文件名 与 inode 编号的映射关系inode

  这也就解释了为什么删除源文件后，硬链接文件不受任何影响，仅仅只是 硬链接数 - 1，同理，删除硬链接文件，也不会影响源文件

  为什么新建目录的硬链接数为 2 ？

1. 因为一个目录在新建后，其中默认存在两个隐藏文件：. 与 …
2. 其中 . 表示当前目录，… 表示上级目录

  Linux 中的目录结构为多叉树，即当前节点（目录）需要与父节点（上级目录）、子节点（下级目录）建立链接关系，并且还得知道当前目录的地址，否则就会导致切换目录时出现错误

  为了避免因用户的误操作而导致的目录环状问题，规定用户不能手动给目录建立硬链接关系，只能由 OS 自动建立硬链接，比如新目录后，默认与上级目录和当前目录建立硬链接文件，在当目录下创建新目录后，当前目录的硬链接数 + 1

所以说，将目录的硬链接数 - 2 ，得到的数字就是该目录下的目录数

  4 - 2 = 2，所以目录 gitQuest 下一共有2个目录，我们来验证一下：

应用场景

  软链接可以当作快捷方式使用，比如快速运行一个藏的很深的可执行程序

  而硬链接一是可以用来当作目录移动的工具，二是可以用来给重要的源文件起别名并使用，一旦发生删除等不可逆行为时，可以确保源文件的安全

  注意： 硬链接并不是将源文件直接进行备份，而是新建立 inode 编号与硬链接文件名的映射关系，同时 struct inode 中的引用计数 ref_count++，只有当 ref_count == 1 时才会真正删除文件内容及属性， 否则都只是在取消映射关系和 ref_count–

取消链接

取消链接的方式有两种：

1. 直接删除链接文件
2. 通过 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环境下编码的时候，语法提示是如何做到的？

1. 安装开发环境，实际上是在安装编译器、开发语言配套的库和头文件
2. 编译器的 语法提示功能来源于头文件（语法提示其实就是搜索）

我们在写代码时，开发环境是怎么知道语法错误或其他错误的？

1. 编译器有命令行模式，还有其他自动化模式，编写代码时，不断进行主动编译，排查错误

三、制作静态库

  现在有一些简单的计算 函数，能满足整型的 计算

  主函数中将对这些自定义的库函数进行调用

静态库的打包

  一共分为两步：

1. 将源文件进行 预处理 -> 编译 -> 汇编，生成可链接的二进制 .o 文件
2. 通过指令将 .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/

  注意： 将自己写的文件安装到系统目录下是一件危险的事（导致系统环境被污染），用完后记得手动删除

四、制作动态库

动态区的打包

  动态库不同于静态库，动态库中的函数代码不需要加载到源文件中，而是通过 与位置无关码 ，对指定函数进行链接使用

动态库的打包也同样分为两步：

1. 编译源文件，生成二进制可链接文件，此时需要加上 -fPIC 与位置无关码
2. 通过 gcc/g++ 直接目标程序（此时不需要使用 ar 归档工具）

  将源文件编译为 .o 二进制文件，此时需要带上 fPIC 与位置无关码

  将所有的 .o 文件打包为动态库（借助 gcc/g++）

gcc -o libmycalc.so *.o -shared

  获得动态库后，就可以进行使用了

动态库的链接与使用

  像使用静态库一样使用动态库（指定路径及库名），编译成功，但运行失败！

  为什么会出现这种问题？ 因为当前只告诉了编译器动态库的位置，没有告诉 OS

通过 查看程序链接情况：ldd

运行时， 是如何链接动态库？OS

1. 环境变量 LD_LIBRARY_PATH （默认没有这个环境变量），将第三方动态库路径添加至此环境变量中（临时方案）
2. sudo 在 /lib64/ 目录下建立动态库的软链接
3. 更改配置文件 /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

  只有当一个库被真正映射进地址空间后，它的起始地址才能真正确定

• 链接库中的函数时，通过 动态库的起始地址 + 函数偏移量 的方式链接函数
• 这种方法不论在什么位置，都可以随便链接函数（与位置无关）
• 与位置无关码：动态库中地址，是偏移量

---

总结

最后还有需要总结的一些要点就是：

1. 当同时拥有 静态库 和 动态库 时，默认采用动态链接
2. 可以在编译的时候最后加上 -static 指定 静态链接
3. 只有静态库，又不指定静态链接，这个时候是动态链接（内含静态库）
4. 静态链接生成的程序比动态链接大得多，并且内含静态库的动态链接程序，也比纯粹的动态链接程序大，程序并非非静即动

  另外，你可不可以利用 Makefile 来简化步骤？