文章目录
引言
在计算机的无形世界中，数据如河流般流淌，而文件系统则是河道的设计者。Linux，这位古老而睿智的守护者，为我们铺设了一条通往数字王国深处的道路。
今天，让我们踏上一段奇妙的旅程，探索Linux基础I/O中那些看似平凡却蕴含无限智慧的链接与库。
1、软硬链接
1.1、基本认知
对文件进行软硬链接非常简单，只需要通过ln -s或ln对文件进行链接即可，生成的链接文件类型为 l（普通文件为 -，目录文件为 d）
对文件
test.cc进行软链接，生成软链接文件my-sort，其中软链接文件名可以自定义
ln -s test.cc my-soft.cc
需要注意在后续对软链接编译生成可执行程序时，如果my-soft.cc没有文件后缀，会存在无法识别问题
生成硬链接文件就更简单了，对文件
test.cc进行硬连接，生成硬连接文件my-hard，其中硬链接文件名也可以自定义
ln tets.cc my-hard
生成的软硬链接文件如何使用呢？
- 像源文件一样使用即可，结果一模一样（因为当前软硬链接的都是同一个源文件）
虽然此时的软硬链接执行结果一致，但这两种链接方式在本质上有很大区别 - 软链接文件的
inode编号与源文件不同（独立存在），软连接文件比源文件小得多，并且软连接文件->源文件 - 硬链接文件与源文件共用一个
inode 编号（对源文件其别名），硬链接文件与源文件一样大，并且硬链接文件与源文件的链接数变成了 2
软链接文件依赖于源文件，而硬链接文件是源文件的别名
当我们将源文件删除后，软连接失效；硬链接仍然有效，不过硬链接数变为了 1
1.2、实现原理
软链接又称为符号链接，它是一个单独存在的文件，拥有属于自己的inode属性及相应的文件内容，不过在软连接的Data block中存放的是源文件的地址，因此软连接很小，并且非常依赖于源文件
因此如果源文件被删除了，那么在执行软连接文件时，其中的地址就是一个无效地址（目标文件已丢失），此时就会报错
No such file or directory假设只是单纯的删除软连接文件，那么对源文件的内容没有丝毫影响，就好比 Windows 桌面上的
快捷方式，有的人以为将快捷方式（软链接）文件删除了，就是在 “卸载” 软件，其实不是，如果想卸载软件，直接将其源文件相关文件夹全部删除即可硬链接并非创建一个相同的文件进行链接，而是在源文件所目录下的
【inode编号 与文件名对应表中】，新增【inode 编号与硬链接文件名】的映射关系，并将inode结构体中的引用计数+1，表示当前已成功硬链接上了一个文件
- 当删除当前
inode对应文件时，会 先判断ref_count是否为 1，如果是，才会将文件内容及其属性真正删除，- - 否则删除的只是 文件名 与 inode 编号的映射关系
这也就解释了为什么删除源文件后，硬链接文件不受任何影响，仅仅只是 硬链接数 - 1，同理，删除硬链接文件，也不会影响源文件
为什么新建目录的硬链接数为 2？
- 因为一个目录在新建后，其中默认存在两个隐藏文件：
.与.. - 其中
.表示当前目录，..表示上级目录
Linux 中的目录结构为多叉树，即当前节点（目录）需要与父节点（上级目录）、子节点（下级目录）建立链接关系，并且还得知道当目录的地址，否则就会导致切换目录时出现错误
为了避免因用户的误操作而导致的目录环状问题，规定用户不能手动给目录建立硬链接关系，只能由 OS 自动建立硬链接
比如创建新目录后，默认与上级目录和当前目录建立硬链接文件，在当目录下创建新目录后，当前目录的硬链接数 + 1
小技巧：将目录的硬链接数 - 2，就可以知道该目录中有多少个目录了
ls -d //只查看目录文件
1.3、应用场景
软链接可以当作快捷方式使用，比如快速运行一个藏的很深的可执行程序
硬链接
- 可以用来当作目录移动的工具
- 可以用来给重要的源文件起别名并使用，一旦发生删除等不可逆行为时，可以确保源文件的安全
注意： 硬链接并不是将源文件直接进行备份，而是新建立 inode 编号与硬链接文件名的映射关系，同时 struct inode 中的引用计数 ref_count++，只有当 ref_count == 1 时才会真正删除文件内容及属性，否则都只是在取消映射关系和 ref_count--
1.4、取消链接
取消链接的方式有两种：
- 直接删除链接文件
- 通过
unlink取消链接关系
1.5、ACM时间
每一个文件都有三个时间：
- 访问 Access
- 修改属性 Change
- 修改内容 Modify
简称为 ACM 时间
可以通过stat查看指定文件的 ACM 时间信息
2、动静态库
接下来学习动静态库的相关内容，了解程序运行时是如何调用资源的
2.1、认识库
常见的库文件：stdio.h、stdlib.h、string.h 等
库分为 动态库 和 静态库
- Linux 中，.a 后缀为静态库，.so 后缀为动态库
- Windows 中，.lib 后缀为静态库，.dll 后缀为动态库
虽然不同环境下的后缀有所不同，但其工作原理是一致的
库命名
- 比如 libstdc++.so.6
- 去掉前缀跟后缀,最终库名为 stdc++
查看当前环境中的库文件
ls /usr/lib/x86 64-linux-gnu/libc*
- 无论是
C语言还是C++，在编写程序时，一定离不开库文件，比如之前模拟实现的FILE 类型，就位于 stdio.h 这个库中。 - 动态库优势比静态库明显，因此在编译代码时，默认采用动态链接的方式，如果想指定为静态链接编译，只需要在
gcc/g++语句后面加上-static即可（前提是得有静态库）
观察可得，静态库编译得到的程序大小远大于动态库。
关于动静态库的优缺点可以看看下面这个表格：
注意： 静态库是将所需要的函数代码拷贝到源文件中直接使用，而动态库是通过动态链接的方式，进行函数链接使用
2.2、库的作用
所以，库文件到底有什么用？
- 提高开发效率
系统已经预装了 C/C++ 的头文件和库文件，头文件提供说明，库文件提供方法的实现
- 头和库是有对应关系的，需要组合使用
- 头文件在预处理阶段就已经引入了，链接的本质就是在链接库
简言之，如果没有库文件，那么你在开发时，需要自己手动将 printf 等高频函数编写出来，因此库文件可以提高我们的开发效率，比如 Python 中就有很多现成的库函数可以使用，效率很高
语法提示是如何做到的？
- 安装开发环境
- 实际上是在安装编译器、开发语言配套的库和头文件
编译器的
语法提示功能来源于头文件（语法提示其实就是搜索）我们在写代码时，开发环境是怎么知道语法错误或其他错误的？
- 编译器有命令行模式，还有其他自动化模式，编写代码时，不断进行主动编译，排查错误
3、制作静态库
现在有一些简单的计算 demo 函数，能满足整型的 ± 计算，将这些代码作为库进行打包
myadd.h
#pragma once
//声明功能
int add(int x, int y);
myadd.c
#include "myadd.h"
//定义功能
int add(int x, int y)
{
return x + y;
}
mysub.h
#pragma once
//声明功能
int sub(int x, int y);
mysub.c
#include "mysub.h"
//定义功能
int sub(int x, int y)
{
return x - y;
}
主函数中将对这些自定义的库函数进行调用
test.c
#include <stdio.h>
#include "myadd.h"
#include "mysub.h"
int main()
{
printf("2 + 3 = %d\n", add(2, 3));
printf("18 - 6 = %d\n", sub(18, 6));
return 0;
}
3.1、静态库的打包
静态库的打包主要分为以下两步：
- 将源文件进行 预处理->编译->汇编，生成可链接的二进制 .o 文件
- 通过指令将 .o 文件打包为静态库
将文件编译为 .o 二进制文件
gcc -c myadd.c mysub.c
将所有的.o文件打包为一个静态库（库名自定义）
其中的mycalc为库名
ar -rc libmycalc.a *.o
ar是GNU提供的归档工具，常用来将目标文件打包为静态库- 我们还可以使用 ar 反向查看静态库中的具体文件
ar -tv静态库文件
获得静态库后，就可以进行使用了
注：此时的 .h、.c、.o 文件位于 lesson20 文件夹中，而静态库文件 .a 位于mylib文件夹中
3.2、静态库的使用
方法一：通过指定路径使用静态库
如果直接编译程序，会出现编译失败的情况，因为编译器不认识第三方库（需要提供第三方库的路径及库名）
第一方库：语言提供
第二方库：操作系统提供
第三方库：other 提供的库，比如当前我们直接打包的静态库
对于自己写的的第三库的使用，需要标注三个参数：
-I 所需头文件的路径 需要将所需头文件的路径加上，因为此时路径已经为所需路径，因此此处为 ./
-L 所需库文件的路径 这里加的是库文件的路径，也为 ./
-l 待链接静态库名 所需要链接的静态库名字，这里为 mycalc
gcc -o ret test.c -I./ -L./ -lmycalc
为什么编译 C/C++ 代码时，不需要指定路径？
- 因为这些库都是系统级的，gcc/g++ 默认找的就是 stdc/stdc++ 库
方法二：将头文件和静态库文件安装至系统目录中
除了这种比较麻烦的指定路径编译外，我们还可以将头文件与静态库文件直接安装在系统目录中，直接使用，无需指定路径（需要指定静态库名）
所谓的安装软件，就是将自己的文件安装到系统目录下
sudo cp ./*.h /usr/include/
sudo cp libmycalc.a /usr/lib/x86_64-linux-gnu
注意： 将自己写的文件安装到系统目录下是一件危险的事（导致系统环境被污染），用完后记得手动删除
4、制作动态库
除了可以制作静态库外，我们还可以制作动态库，这里用的例子和上面一样
4.1、动态库的打包
动态库不同于静态库，动态库中的函数代码不需要加载到源文件中，而是通过 与位置无关码 ，对指定函数进行链接使用
动态库的打包也同样分为两步：
- 编译源文件，生成二进制可链接文件，此时需要加上 -fPIC 与位置无关码
- 通过 gcc/g++ 直接目标程序（此时不需要使用 ar 归档工具）
将源文件编译为.o二进制文件，此时需要带上 fPIC 与位置无关码
gcc -c -fPIC *.c
将所有的 .o 文件打包为动态库（借助 gcc/g++）
gcc -o libmycalc.so *.o -shared
获得动态库后，就可以进行使用了
注：此时的 .h、.c、.o 文件位于 myinclude 文件夹中，而动态库文件 .so 位于 libmycalc.so 文件夹中
4.2、动态库的链接与使用
像使用静态库一样使用动态库（指定路径及库名），编译成功，但运行失败！
为什么会出现这种问题？因为当前只告诉了编译器动态库的位置，没有告诉 OS
通过ldd查看程序链接情况：
当前尚未链接
运行时，OS ·是如何链接·动态库？
- 环境变量·
LD_LIBRARY_PATH（默认没有这个环境变量），将第三方动态库路径添加至此环境变量中（临时方案） - sudo 在 /lib64/ 目录下建立动态库的软链接
- 更改配置文件
/etc/ld.so.conf.d这个目录中都是各种动态库配置文件，创建文件xx.conf至目录中（文件中存储的是第三方动态库的路径）ldconfig令配置文件生效
以上三种方式都可以正常使用动态库，下面就来逐个进行尝试
方法一：通过环境变量解决
添加动态库路径至 LD_LIBRARY_PATH 环境变量中
环境变量 LD_LIBRARY_PATH 是程序在进行动态库查找时的默认搜索路径
注意： 更改环境变量只是临时方案，重新登录后会失效
方法二：将动态库的软链接文件存入系统目录中
sudo ln -s /home/ccc/lesson20/myinclude/libmycalc.so /lib64/
注意： 创建软连接文件时，需要使用绝对路径！
方法三：更改配置文件中的信息
echo /home/ccc/lesson20/myinclude/libmycalc.so > ccc.conf
sudo mv ccc.conf /etc/ld.so.conf.d/
ls /etc/ld.so.conf.d/ccc.conf
注意： 后两种方法都可以做到永久生效（因为存入了系统目录中），但在使用完后最好删除，避免污染系统环境
4.3、动态库的链接原理
程序在链接动态库函数时，是通过 动态库起始地址 + 所链接函数偏移量 的方式进行链接访问的，而这个偏移量就是 fPIC 与位置无关码
地址其实就两种：绝对地址和相对地址.
- 静态链接时，将可链接的二进制文件加载至程序中，直接通过
绝对地址 进行链接，假设函数被调用了多次，就会导致代码冗余等问题； - 动态链接采用
相对地址的方式进行链接，同一个函数的动态库起始地址+所链接函数偏移量值相同，代码只需要加载一份，并且可以任意位置进行函数调用（与位置无关）
动态库中所有地址都是偏移量，默认从 0 开始
只有当一个库被真正映射进地址空间后，它的起始地址才能真正确定
- 链接库中的函数时，通过
动态库的起始地址 + 函数偏移量的方式链接函数 - 这种方法不论在什么位置，都可以随便链接函数（与位置无关）
- 与位置无关码：动态库中地址，是偏移量
5、动态库知识补充
当同时拥有
静态库和动态库时，默认采用动态链接如果只有静态库，但又不指定静态链接，会发生静态库文件
静态链接生成的程序比动态链接大得多，并且内含静态库的动态链接程序，也比纯粹的动态链接程序大，说明程序不是·
非静即动，可以同时使用动态库与静态库
本篇关于软硬链接与动静态库的介绍就暂告段落啦，希望能对大家的学习产生帮助，欢迎各位佬前来支持斧正！！！
