时间戳

首页 > 解决方案 > 如何永久且适当地替换本机动态库文件

linux - 如何永久且适当地替换本机动态库文件

问题描述

我尝试开发一个第三方的unixODBC驱动，它是在原文件libodbc.so.2.0.0的基础上二次开发的。

所以我想将“libodbc.so.2.0.0”重命名为“libodbc.so.2.0.0_renamed”。并将我的动态库文件软链接到 libodbc.so.2.0.0。

但是我发现一个困扰我的问题，当我重命名本机文件并运行“sudo ldconfig”时，名为“libodbc.so.2”的文件会自动链接到重命名的文件“libodbc.so.2.0.0_renamed”，如下所示： 贝壳图

我无法理解：

我对linux没有足够的认识，所以我没有找到任何关键字来搜索和处理它。

能不能帮帮我，非常感谢！

标签： linuxodbcshared-librariesunixodbcdynamic-library

解决方案

GNU/Linux 下的共享对象遵循特定的版本命名方案，加载程序（和 OS 组件，实际上是 libc 框架的一部分）知道该方案，以确定较新的库是否与二进制文件最初所在的旧版本兼容链接反对。通过添加renamed后缀，您违反了约定，并且动态链接系统变得混乱。您应该按照上面@Bodo 的建议重命名。

此外，rename您可能会考虑使用版本控制方案，而不是使用 . 从 GNU Build System (aka Autotools) 手册中，版本方案如下：

Versioning: CURRENT:REVISION:AGE                                               
CURRENT The latest interface implemented.                                      
REVISION The implementation number of CURRENT (read: number of bugs fixed...)  
AGE The number of interfaces implemented, minus one.                           
The library supports all interfaces between CURRENT − AGE and CURRENT.         
                                                                                
If you have                                                                    
not changed the interface (bug fixes)         CURRENT : REVISION+1 : AGE       
augmented the interface (new functions)       CURRENT+1 : 0 : AGE+1            
broken old interface (e.g. removed functions) CURRENT+1 : 0 : 0

因此，您的库的可能历史可能是：

1:0:0   start
1:1:0   bug fix
1:2:0   bug fix
2:0:1   new function
2:1:1   bug fix
2:2:1   bug fix
3:0:0   broke api
3:1:0   bug fix
4:1:1   bug fix
5:0:0   broke api

例如，您可以根据需要调用旧版本和新版本的 libodbc.so.xyz。只是一个想法。

推荐阅读