码迷,mamicode.com
首页 > 系统相关 > 详细

解决Linux动态库版本兼容问题

时间:2019-10-27 20:47:31      阅读:110      评论:0      收藏:0      [点我收藏+]

标签:net   资源   name   运行   智能   默认   html   输出   embed   

说道“动态库版本兼容”,很多人头脑中首先蹦出的就是“Dll Hell”。啊,这曾经让人头疼的难题。时至今日,这个难题已经很好地解决了。
 
在进一步讨论之前来思考一个问题:Linux下为什么没有让人头痛的“DllHell”?
回答这个问题,非常easy,因为——Linux下根本没有dll!
 
哈哈,当然这只是个玩笑,接下来展开一下这个话题,很多有动态库的系统都会面临这个难题,但各自解决的思路却各不相同。
 
Dll hell是指windows 上动态库新版本覆盖旧版本,但是却不兼容老版本。常常发生在程序升级之后,动态库更新,原有程序运行不起来;或者装新软件,但是已有的软件运行不起来。
 
一、linux下的解决方案——命名规范
Linux 上的Dll ,叫sharedlibrary。Linux 系统面临和Window一样的问题,如何控制动态库的多个版本问题。为解决这个问题,Linux 为解决这个问题,引入了一套命名机制,如果遵守这个机制来做,就可以避免这个问题。但是这只事一个约定,不是强制的。但是建议遵守这个约定,否则同样也会出现 Linux 版的Dll hell 问题。
 
Real Name
首先是共享库本身的文件名:共享库的命名必须如 libname.so.x.y.z
最前面使用前缀”lib”,中间是库的名字和后缀”.so”,最后三个数字是版本号。x是主版本号(Major Version Number),y是次版本号(Minor Version Number),z是发布版本号(Release Version Number)。
 
主版本号(不兼容):重大升级,不同主版本的库之间的库是不兼容的。所以如果要保证向后兼容就不能删除旧的动态库的版本。
 
次版本号(向下兼容): 增量升级,增加一些新的接口但保留原有接口。高次版本号的库向后兼容低次版本号的库。
 
发布版本号(相互兼容):库的一些诸如错误修改、性能改进等,不添加新接口,也不更改接口。主版本号和此版本号相同的前提下,不同发布版本之间完全兼容。
 
SO-NAME
严格遵守上述规定,确实能避免动态库因为版本冲突的问题,但是读者可能有疑问:在程序加载或运行的时候,动态链接器是如何知道程序依赖哪些库,如何选择库的不同版本?
Solaris和Linux等采用SO-NAME( Shortfor shared object name )的命名机制来记录共享库的依赖关系。每个共享库都有一个对应的“SO-NAME”(共享库文件名去掉次版本号和发布版本号)。比如一个共享库名为libtest.so.3.8.2,那么它的SO-NAME就是libtest.so.3。
 
 
在Linux系统中,系统会为每个共享库所在的目录创建一个跟SO-NAME相同的并且指向它的软连接(Symbol Link)。这个软连接会指向目录中主版本号相同、次版本号和发布版本号最新的共享库。也就是说,比如目录中有两个共享库版本分别为:/lib/libtest.so.3.8.2和/lib/libtest.so.3.7.5,么软连接/lib/libtest.so.3指向/lib/libtest.so.3.8.2。
 
建立以SO-NAME为名字的软连接的目的是,使得所有依赖某个共享库的模块,在编译、链接和运行时,都使用共享库的SO-NAME,而不需要使用详细版本号。在编译生产ELF文件时候,如果文件A依赖于文件B,那么A的链接文件中的”.dynamic”段中会有DT_NEED类型的字段,字段的值就是B的SO-NAME。这样当动态链接器进行共享库依赖文件查找时,就会依据系统中各种共享库目录中的SO-NAME软连接自动定向到最新兼容版本的共享库。
 
 readelf -d sharelibrary 可以查看so-name
 Linux提供了一个工具——ldconfig,当系统中安装或更新一个共享库时,需要运行这个工具,它会遍历默认所有共享库目录,比如/lib, /usr/lib等,然后更新所有的软链接,使她们指向最新共享库。
 
Link Name
 
当我们在编译器里使用共享库的时候,如用GCC的“-l”参数链接共享库libtXXX.so.3.8.1,只需要在编译器命令行指定 -l XXX 即可,省略了前缀和版本信息(也就是说可以指定详细的版本信息??,有机会测试一下假设指定libuser.so.1.1.2,然后/usr/lib里只有libuser.so.1或其它版本Linux能否智能的查找)。编译器会根据当前环境,在系统中的相关路径(往往由-L参数指定)查找最新版本的XXX库。这个XXX就是共享库的“链接名”。不同类型的库可能有相同的链接名,比如C语言运行库有静态版本(libc.a)也动态版本(libc.so.x.y.z)的区别,如果在链接时使用参数”-lc”,那么连接器就会根据输出文件的情况(动态/静态)来选择合适版本的库。eg. ld使用“-static”参数时吗,”-lc”会查找libc.a;如果使用“-Bdynamic”(默认),会查找最新版本的libc.so.x.y.z。
 
更详细可以参见
http://www.linuxidc.com/Linux/2012-04/59071.htm
 
 
.Net下的解决方案——Manifest文件
.Net框架中,一个程序集(Assembly)有两种类型:应用程序程序集(.exe)与库程序集(DLL动态链接库)。一个程序集包括一个或个文件,所以需要一个清单文件(Manifest文件)来描述程序集。Manifest文件描述了程序集的名字,版本号以及程序集的各种资源,同时也描述了该程序集的运行所依赖的资源,包括DLL以及其他资源文件等。Manifest是一个XML文件。每个DLL有自己的Manifest。对于应用程序而言,manifest文件可以和可执行文件在同一目录,也可以作为一个资源嵌入到可执行文件内部(Embed Manifest)。
 
XP以前的windows版本,在执行可执行文件是不会考虑manifest文件的。它会直接到system32目录下查找可执行文件锁依赖的DLL。在这种情况下,manifest是多余的。XP之后的操作系统,在执行可执行文件时则会首先读取程序集的manifest文件,获得该可执行文件需要调用的DLL列表,操作系统再根据DLL的manifest文件去寻找对应的DLL调用。
 
 
Windows的解决方案——COM组件
采用标准COM组件,有很多好处:面向接口和对象编程语言无关性,采用二进制标准,可以实现跨语言调用版本升级方便,增加新接口,组件升级后老客户程序不用重新编译位置透明,客户程序不用关心组件的位置重用方便,通过包容和聚合可以快速重用已有组件我们可以看到标准COM组件非常强大,但是很多时候我们并不需要标准COM组件的所有特性,比如我们不希望引入注册表,也不希望引入COM运行库,我们希望我们的程序是完全“绿色”的。这时我们就会采用“COM思想架构“开发非标准的COM组件。


转自 http://blog.sina.com.cn/s/blog_5cf54f0e0101cpct.html

解决Linux动态库版本兼容问题

标签:net   资源   name   运行   智能   默认   html   输出   embed   

原文地址:https://www.cnblogs.com/silentdoer/p/11748620.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!