🌈欢迎来到Linux专栏~~动静态库的制作与使用
- (꒪ꇴ꒪(꒪ꇴ꒪ )🐣,我是Scort
- 目前状态:大三非科班啃C++中
- 🌍博客主页:张小姐的猫~江湖背景
- 快上车🚘,握好方向盘跟我有一起打天下嘞!
- 送给自己的一句鸡汤🤔:
- 🔥真正的大师永远怀着一颗学徒的心
- 作者水平很有限,如果发现错误,可在评论区指正,感谢🙏
- 🎉🎉欢迎持续关注!
动静态库的制作与使用
一.动态库 & 静态库
可能大家都快要忘记了这方面的知识,下面来复习一下 ,也可以来看看这篇博客->🔥动静态库🔥
在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总算完结了,进程通信我来了