一.动态库 & 静态库
可能大家都快要忘记了这方面的知识，下面来复习一下 ，也可以来看看这篇博客->🔥动静态库🔥
在Linux中，一般库分为两种：动态库和静态库，它们就是文件！
静态库 ：库文件以.a为后缀
动态库 ：库文件以.so为后缀
库文件的命名规则：libname.so 或者 libname.a [.后面可能跟其他的内容]
库的真实名字：掐头去尾就是库名称。即去掉lib前缀并去掉.so/.a后缀，如上文中的c库
（在windows中，动态库以.lib为后缀，静态库以.dll为后缀）
我还记得gcc在编译的时候动态链接编译的，如果需要静态链接编译 则要带-static
可以观察到动态链接时文件体积较小，静态链接时文件体积较大。
原因很简单嘛，静态链接是把库文件的有关代码拷贝到我的可执行文件中，因此生成的文件比较大，可移植性较好。而动态链接，是在程序执行时由运行时链接文件加载库（地址），这样可以节省内存和硬盘的空间
我们买的云服务器没有内置语言的静态库，而只有动态库，需要yum安装C/C++静态库
sudo yum install glibc-static
sudo yum install libstdc++-static
二. 制作静态库
问了一个小问题：库里面要不要main函数呢？
答案是不能有，库是给别人用的，两个main函数会冲突
准备工作：
不出意外，编译成功了
但库的制作只是这么简单？这还远不能称为制作库
我们知道编译时，只要把源文件编译成.o文件，再将其链接起来成为一个可执行程序
这下问题来了，我只把编好的.o和.h给人家,别人能用吗？
答案是：可以的
但是如果.o文件过多呢？
我们可以把一堆.o文件以某种方式打包，这种过程叫做形成库
🌈制作（编写者角度）
mklib目录下写这样一个Makefile ~
💦 1. 将库文件全部编译为.o
💦 2. 再用ar命令，把所有的.o打包在一起
可是怎么样打包呢？
ar -rc libname.a [待打包.o] //举例： ar -rc libhello.a mymath.o myprint.o
ar是gnu的归档工具（Archive files），相当于打包成指定名称的文件
rc表示replace and create
hello库 —— include（包含库的所有头文件） —— lib （包含对应的库文件）
这样就打包了库
🌈使用（使用者角度）
立即把装好的库，拿来用一下
编辑main.c的时候发现一大堆错误
这下咋搞呢？
库的安装：把头文件和库文件拷贝进系统中（不建议：第三方库没经过测试，会污染其他的头文件）
头文件 gcc的默认搜索路径是 ： /usr/include；库文件的默认搜索路径是： /lib64 or /usr / lib64
硬使用：显性的告诉编译器各种文件在哪
因为不在当前路径上，也不在库上，所以搜索不到
🌍直接编译会报错：找不到头文件。那当然找不到，编译器并不会查找你同级目录下目录中有啥， 因此要带-I./lib，指明在当前目录下的lib目录下找；
🌍又报错说找不到库函数的实现，因此带-L./lib，要告知库路径在哪儿
🌍但是实际情况可能有很多库，编译器也不知道链接这个路径下哪个库，因此同时要指定库。
-lhello(-l＋库名)
-I：指明头文件搜索路径
-L: 指明库文件搜索路径
-l： 指明要链接哪个库
三. 制作动态库
🥑制作
🎨还是要将库文件全部编译为.o，只不过要带选项-fPIC，形成与位置无关码
gcc -fPIC -c mymath.c -o mymath.o
什么叫做与位置无关的目标二进制文件呢？
静态库使用的是绝对编址，动态库采用相对编址（段地址 + 偏移），无需精准的地址
举个例子：
🎨 要把库打包，我们不再使用ar命令，记得带选项-shared ，告诉gcc形成动态库了而不是可执行程序
gcc -shared myprint.o mymath.o -o libhello.so
🎨接下来就是在makefile形成库并且打包发布的过程，形成动态库和静态库
🥑使用
tar打包 发到网上
tar czf mylib.tgz output
🌊同样的我们需要指定路径搜索头文件-I./lib，同样的也需要指明库文件的搜索路径-L./lib，同样的也要指明链接哪个库
gcc main.c -I output/include -L output/lib -lhello
编译器默认的就是动态链接
如果是只有静态库，就会把静态库拷贝进a.out中，gcc只能对该库进行静态链接
如果动静态库同时存在，默认就用动态库
如果我就想用静态库：-static：摒弃默认优先使用动态库的原则，使用静态库
但是一运行./a.out就报错了。因为静态库把目标模块直接拷贝进去，运行时不需要再找；而动态库，编译时需要找，运行时也需要加载动态库
静态库文化和本身的代码是放在了一起的；如果有重复的进程要调用，动态库：直接建立页表与内存的映射关系，也就可以跳转访问了；所以动态库加载一次就可以被多个进程所共同使用。静态库：多少次调用就有多少个拷贝，如果是十个一样的程序调用，那可能有9个是重复的
可是刚刚我编译时不是已经告诉了库路径了吗？为什么还是说我找不库？ 奇怪
⚡但这只是告知了编译器gcc头文件库路径在哪里，当程序编译完成后，已与编译器无关，运行的时候加载器还是不知道它们在哪儿（所以报错）
也就是形成了a.out后，要和系统说动态库在哪
✨ 于是 —— 咱们需要在运行时前一步告知系统库在哪，有这样4种常见做法：
动态库头文件拷到共享库路径/lib64下（强烈不建议，污染）
通过导入LD_LIBRARY_PATH这个环境变量，指明程序启动后动态库的搜索路径（最推荐的）
在我们的服务器一般是空空如也的 —— 接下来我们导入进去
export LD_LIBRARY_PATH=路径 #导入环境变量
当然了，这种在命令行设置的环境变量，只在本次会话有效，退出登陆后再进来就没了。
如果想让环境变量永久生效，可以把它添加到登陆的启动脚本里（强烈不推荐）
比如vim ~/.bash_profile或者vim ~/.bashrc
修改系统文件：配置系统文件/etc/ld.so.conf.d/，是系统搜索动态库的路径，这种做法可以永久生效
在这里我们打开任意一个看看，其中也不过是一个配置路径
我们需要以sudo提升权限 进入：①添加配置文件，②在其中添加库的搜索路径，③并更新缓存。
然后我们执行，更新配置文件的缓存
ldconfig //更新库路径缓存
后面就开始生效了（再次登录也有效）
如果你把这配置文件删了，那当然又不行了
[root@VM-24-5-centos ld.so.conf.d]# rm oneManBand.conf [root@VM-24-5-centos ld.so.conf.d]# ldconfig
我们还是推荐添加环境变量的，虽然麻烦点，但是为了后面熟悉上手
为什么要有库？
使用库的角度：站在巨人的肩膀上，库的存在可以大大减少我们开发的周期，提高软件本身的质量
写库人的角度： 1.简单 2. 代码安全（不暴露底层代码）
总结一下
📢写在最后
基础IO总算完结了，进程通信我来了
