目录
一、软硬链接
软硬链接的本质区别就是：有无独立的inode
软链接有独立的inode，也就意味着软链接是一个独立的文件
硬链接没有独立的inode，即硬链接并不是一个独立的文件
ln -s是软链接的语法，不加-s就是硬链接
上图将soft.txt与testlink1软链接，将hard.txt与testlink2硬链接，通过ls -li(-i表示显示对应的inode值)，可以看出进行软链接的soft.txt与testlink1的inode不同，而进行硬链接的hard.txt与testlink2的inode却是相同的，即表示硬链接没有独立的inode
1、软链接
软链接相当于Windows下的快捷方式，如下所示：
我们有一个文件夹test
test里还有个文件夹hello，hello里有个文件test.c，test.c经过gcc形成可执行文件test.exe，test.c文件内容如下：
如果在当前路径下，想运行这个test.exe这个可执行文件：
即使通过相对路径的方式运行，也是比较麻烦的，所以这时使用软链接：
将该路径下的test.exe与test/hello/下的test.exe建立软链接，这时如果想执行刚刚的可执行文件，只需运行test.exe即可：
所以软链接相当于Windows下的快捷方式
可以理解为：软链接的文件内容，是指向的文件对应的路径
unlink删掉软链接
2、硬链接
由于硬链接没有独立的inode，所以硬链接不是独立的文件，所以创建硬链接并不是真正的创建新文件，而是在指定的目录下，建立了文件名和指定inode的映射关系，也就是起别名
在ls -li时，我们可以发现这样一个属性：
这样的数字表示的就是硬链接数
例如我们上面将hard.txt与testlink2硬链接了，所以他们共同的这个硬链接数属性就是2：
而如果删除其中一个：
这时hard.txt的硬链接数就变为了1
所以当我们删除一个文件时，并不是删除文件的inode，而是将inode中包含的引用计数count即硬链接数--，直到引用计数为0，这个文件才真正的删除了
下面看下一个问题，分别创建一个目录dir和一个普通文件test.c：
为什么dir的硬链接数是2，而普通文件的硬链接数是1
其实很简单，当我们创建普通文件test.c时，创建出来后，test.c这个文件名映射到自己的inode，所以硬链接数为1
而目录dir，创建出来后，自己的目录名dir映射到自己的inode，这是其中一个；自己目录内部有一个 . ，也与inode有对应的映射关系，这时第二个，因此目录的硬链接数默认为2
这也就是我们平时运行可执行文件时是./test.exe，前面的.也就是表示是在当前路径下
而如果我们在dir目录下，再创建一个dir1目录：
这时dir的硬链接数变为了3，这又是什么原因呢
其实也很简单，我们分别进入dir和dir1，都进行ls -lia，列出详细信息
可以发现dir中的 . 与dir1中的 .. 的inode都是790425，所以我们就清楚这里的第三个硬链接数就是来自dir1中的 ..
因此也就能解释，为什么cd ..就是返回上一级路径，原因就是这里的..与上一级路径的inode是相同的，也就是当前路径的..就是上一级路径的别名，所以cd ..就是返回上一级路径
.和..就是下图所表示的关系：
因此如果我们继续在dir中创建目录，硬链接数也就会增加：
原本是3，再mkdir两个就变为5，经过上面讲解，就可以知道新增的2个就是dir2和dir3中的 .. ，所以通过这一点，我们以后观察目录的硬链接数数是多少，只需要-2(减去的是dir与dir中的.这两个对应关系)，就是里面包含的目录数
所以上面的dir硬链接数是5，-2即包含的目录有三个，分别是dir1/2/3：
二、动态库和静态库
关于动静态库，我们前面的博客也提到过，Linux中，静态库是.a结尾，动态库是.so结尾
下面要讲到的动静态库的制作和使用，都是为了后续更好的使用别人的库做准备
编写一个库
首先明确一点，库中不能有main函数，因为库是给别人用的，如果有main函数，别人也有main函数，就重复定义了
①静态库
首先有一个mklib的目录（制作库），里面有四个文件，分别是：
myadd.h、myadd.c、myshow.h、myshow.c
myadd.h
myadd.c
myshow.h
myshow.c
然后创建一个目录uselib（使用库），
里面有main.c，用于使用myshow和myadd
下面可以初步使用一下，首先将mkdir中的myadd.c和myshow.c变为.o文件：
然后将所有.o和.h文件都cp到uselib中，再将main.c也变为.o文件：
此时uselib中就有全部的.c和.h文件，这时生成可执行exe文件并运行：
是能够运行的
但是这种方式.o文件太多了，拷贝给别人使用时不方便，且编译时这些.o文件都需要打上去，万一不留神少打一个.o文件，就会出问题
所以我们可以把所有的.o打包，形成一个静态库
语法是：ar -rc [库名] .o文件
ar是归档工具，是归档文件的缩写
-rc中r表示替换，c表示创建
库名：前缀必须是lib，后缀必须是.a
这里的libtest.a就是创建出来的静态库
为了方便，创建Makefile文件：
所以我们就可以make clean清除.o文件与静态库，make生成.o与静态库：
而发布库时，需要include目录和lib目录：
include目录，包含库的所有头文件
lib目录，包含对应的库文件
所以此时在我们的Makefile文件中新增内容：
此时make test，就会生成test的目录，里面有include和lib目录：
至此有了test目录，我们将该目录拷贝到uselib中去使用：
test就是别人的库，而main.c是我准备使用别人的库的main函数
使用静态库的方法
第一种方法：拷贝到库目录下：
头文件gcc的默认搜索路径是：/usr/include
库文件的默认搜索路径是： /lib64
所以将头文件与库文件拷贝到库目录下，编译时就能够找到它们了
将所有.h拷贝到/usr/include中：
这时/usr/include 下就有了myadd.h和myshow.h了
再将libtest.a拷贝到/usr/lib中：
这时/lib64中就有了libtest.a了
而自己写的库是属于第三方库
我们刚刚所写的库名字叫做libtest.a，所以我们gcc时必须表明需要链接的库名，前面加上-l，且将前缀lib和后缀.a都去掉就是库名，即test
生成了一个可执行文件a.out，运行a.out：
至此运行成功，成功使用了静态库libtest.a
我们刚刚的拷贝库到系统的默认路径下，就叫做库的安装
这第一种方法拷贝到库目录下，是不建议的，因为我们自己写的方法并不具有可靠性
第二种方法：直接使用静态库
如果我们直接gcc main.c，会报错：
告诉我们找不到myadd.h，因为默认在库中搜索，搜索不到再到当前路径搜索，而当前路径是uselib，里面并没有.h文件，.h文件在./test/include中，所以-I表示指定让头文件搜索的路径：
这时报错找不到show和add函数，所以-L表示库文件的搜索路径，后面-l跟上特定路径下的库名
这时成功生成a.out可执行文件，./a.out运行成功
总结：gcc main.c -I ./test/include -L ./test/lib -ltest
-I(大写)是头文件的搜索路径，-L是库文件的搜索路径，-l(小写)加上特定路径下的库名
②动态库
动态库的四个函数内容不变，.h和.c也在mklib中，和上面静态库一样
形成的动态库的.o文件必须要加-fPIC选项，.o文件名称加个_d，与静态库保持区分：
而形成动态库，在gcc时需要加上-shared：
-o后面的libtest.so，lib是前缀，.so是后缀，中间的test是库名
此时就生成了libtest.so的动态库
此时了解如何生成的动态库后，就可以把这个过程也编入到Makefile中：
上面的.PHONY:all，是为了一次同时生成静态库和动态库
此时执行make：
可以发现同时生成了静态库和动态库
再执行make test，就会生成test的目录，里面有include和lib目录：
同样我们将该目录拷贝到uselib中去使用：
此时uselib中内容有：
此时动静态库都存在，编译器默认使用动态库：
使用了gcc main.c -I ./test/include -L ./test/lib -ltest，运行a.out时，提醒无法使用动态库，证明了上述结论，使用ldd a.out查看同样可以发现使用的是动态库：
而动静态库都存在时，我们如果想强行使用静态库，需要加上-static选项：
此时就能够执行a.out了
所以站在使用者的角度，得出以下结论：
如果我们只有静态库，gcc只能针对该库进行静态链接
如果动静态库同时存在，默认使用动态库
如果动静态库同时存在，我们加上-static选项可以强行使用静态库
-static的作用：改变默认优先使用动态库的原则，变为直接使用静态库的方案
使用动态库的方法
动态库同样可以像静态库那样，直接拷贝到库目录下，但是我们自己写的库不具有可靠性，所以并不建议这样做，所以这里就不举例这种方式了
第一种方法：添加库所在的位置到LD_LIBRARY_PATH中（临时方案）
LD_LIBRARY_PATH：库加载的搜索路径
系统在搜索库路径时，会在系统的lib64路径下搜素，找到动态库就会使用，如果没找到就终止，如果系统的lib64路径没找到，而LD_LIBRARY_PATH路径也设置了，那就可以在这个路径下搜索
原始的LD_LIBRARY_PATH有下面内容：
我们自己的动态库在这个路径：/home/fcy/lesson2/uselib/test/lib
所以执行：
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/fcy/lesson2/uselib/test/lib
将该路径添加到LD_LIBRARY_PATH中，LD_LIBRARY_PATH=$LD_LIBRARY_PATH:是为了添加时不覆盖之前的内容，用冒号隔开
执行完后，再查看LD_LIBRARY_PATH，就发现刚刚动态库所在的路径被添加到LD_LIBRARY_PATH里面了
这时运行a.out就能成功运行了：
ldd查看a.out：
就会发现，可以查到我们自己的动态库libtest.so
但是这种方法，如果你把你的Xshell软件关了，重新打开一遍，刚刚做的工作就又失效了，所以这种方法只能作为临时方案
第二种方法：添加库所在的位置到/etc/ld.so.conf.d中（永久方案）
系统里有一个路径/etc/ld.so.conf.d，里面保存的是可以自定义配置搜索库路径的永久解决方案：
操作方法很简单，我们先在/etc/ld.so.conf.d里新创建一个普通文件tmp.conf，以.conf结尾（sudo创建）
然后将我们刚刚动态库所在的路径，sudo方式vim打开并粘贴进去：
sudo vim /etc/ld.so.conf.d/tmp.conf
sudo ldconfig，就是让配置文件生效，更新一下
然后运行a.out就能成功运行
ldd a.out也能查看能够找到动态库
第三种方法：软链接方案
在/lib64目录下，创建一个软链接，链接到我们的动态库路径下
这时执行a.out，就能成功执行了：
ldd a.out查看也能找到动态库：
找到的是lib64/libtest.so，而lib64/libtest.so是软链接，所以找到了动态库
不需要时再将这个软链接删掉即可，sudo unlink /lib64/libtest.so
库存在的意义
对于这些库，自然有他们存在的意义
对于使用者来说：
有了库，可以大大减少我们开发的周期，从而提高我们软件的质量
对于开发库的人员角度来说：
第一、使用者使用简单
第二、为了代码安全
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
