
Linux 为解决这个问题,引入了一套机制,如果遵守这个机制来做,就可以避免这个问题。 但是这只事一个约定,不是强制的。但是建议遵守这个约定,否则同样也会出现 Linux 版的Dll hell 问题。 下面来介绍一个这个机制。 这个机制是通过文件名,来控制dll (shared library) 的版本。
Linux 上的Dll ,叫shared library,其有三个名字,分别有不同的目的。
第一个是共享库本身的文件名(real name),其通常包含版本号,常常是是这样: libmath.so.1.1.1234 。 lib是Linux 上的库的约定前缀,math 是共享库名字,so 是共享库的后缀名,1.1.1234的是共享库的版本号,其主版本号+小版本号+build号。主版本号,代表当前动态库的版本,如果动态库的接口有变化,那么这个版本号就要加1;后面的两个版本号(小版本号 和 build 号)是告诉你详细的信息,比如为一个hot-fix 而生成的一个版本,其小版本号加1,build号也应有变化。 这个文件名包含共享库的代码。
第二个是动态库的soname( Short for shared object name),其是应用程序加载dll 时候,其寻找共享库用的文件名。其格式为
lib + math+.so + ( major version number)
其只包含major version number,换句话说,也就是只要其接口没有变,应用程序都可以用,不管你其后minor build version or build version。
问题来了,程序运行时怎么通过soname 找个real name? Soname 存在哪里?如果与real name 关联起来?什么时候存的?
这就是接下来要介绍的第三个共享库的名字,link name,顾名思义,就是在编译过程,link 阶段用的文件名。 其将sonmae 和real name 关联起来。
第三个名字,共享库的连接名(link name),是专门为build 阶段连接而用的名字。这个名字就是lib + math +.so ,比如libmath.so。其是不带任何版本信息的。在共享库编译过程中,连接(link) 阶段,编译器将生成一个共享库及real name,同时将共享库的soname,写在共享库文件里的文件头里面。可以用命令 readelf -d sharelibrary 去查看。
= =看你的创建共享库命令
-soname -libmy.so.1
这里就写明了共享库的名字是libmy.so.1啊!
--library=libmy.so.1 (libc6) =>/usr/lib/--library=ibmy.so.1这个语句的意义是这样的:
有一个调用了libc6的库,名为libmy.so.1,文件放在/usr/lib/里
-soname后面接的是库的名字,除非你强行更改.so文件,是不会变的。
-o后面接的是生成的文件名,会变!
1.编译单个源文件[例如]在屏幕上打印"Hello,Linux."
[源代码]#include<stdio.h
#include<stdlib.h
int main(int argc,char **argv){printf("Hello,Linux.\n")exit(0)}将源文件保存为hello.c,开始进行编译
$gcc -o hello hello.c
编译成功完成后,在当前路径下,生成一个名为hello的文件,然后执行
$./hello在屏幕上,你将会看到打印结果:Hello,Linux.
说明:在默认情况下,编译成功完成后,会在当前路径下,生成一个名为a.out的文件,然后执行$./a.out便可打印结果,但通常可以通过选项-o来指定自己的可执行程序名称
2.编译多个源文件
3.使用外部函数库
4.使用共享函数库和静态函数库5.gcc选项详细描述
欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)