Linux 动态库符号冲突

问题起源

在Linux下编译动态库的时候,所有的符号默认都是导出的,也就是动态库中的函数名,类名等,在外部都是可见的。

当程序引用多个动态库时,由于各个动态库可能属于不同的团队来开发,不同团队使用相同的第三方库的可能性也是有的(例如openssl,libcurl,cjson等),
不同的团队使用的第三方库的版本大概率都是不同的。在编译期间可能不会产生编译错误,但是在运行时可能会导致符号冲突,
引发的现象是调用相同的函数本地测试的结果和运行时的结果不同。

通过修改链接顺序解决问题

既然是不同版本的库相互影响,假设高版本的库能向下兼容,是否可以修改链接顺序,将高版本的库放在前面,低版本的库放在后面,这样就会先加载高版本的库,问题也可以解决
例如libtest1.so,libtest2.so都有openssl库,但是libtest2.so库中openssl版本比较高,那么可以通过修改链接顺序解决问题

LDFLAGS += -Wl,-rpath .  -L . -ltest2 -ltest1

修改链接顺序对于能向下兼容的第三方库是可以解决问题,但是某些第三方库也是不向下兼容的,例如CJSON

通过链接过程中指定优先使用本动态库中的符号

一般而言,单个动态库中并不会出现符号冲突,动态库内部符号冲突一般在编译过程中就会暴露出来,因此当上层程序调用动态库时,
我们可以设置上层程序优先使用本动态库中的符号,而不是全局符号。这样即使其他动态库导出的符号和自己动态库中的符号同名,冲突也不会发生,
运行自己动态库程序的时候会使用自己本动态库中的函数和类。

LDFLAGS += -Wl,-Bsymbolic

注意:这边编译选项必须在被链接的动态库的编译过程中添加,而不是在上层程序链接第三方库的时候添加,例如test引用liba.so,那么这边编译选项需要在编译liba.so过程中添加

通过隐藏符号表解决问题

既然是符号冲突导致的异常,那么可以把库符号信息进行修改,把库内部调用的符号限定为只能内部调用,外部调用的符号限定为可公共调用。一般方法是在函数前增加 __attribute__ 前缀来控制。
在编译过程中加入-fvisibility=hidden选项,因此符号的可见性。对于想要对外暴露的函数通过函数前增加__attribute__((visibility("default")))来指定输出。

gcc  -g -O0 -Wall -fPIC -fvisibility=hidden   -c test.c -o test.o
#ifndef GTC_EXPORT_API
#if defined(_MSC_VER)
#define GTC_EXPORT_API __declspec(dllexport)
#elif defined(__GNUC__)
#define GTC_EXPORT_API __attribute__((visibility("default")))
#else
#define GTC_EXPORT_API
#endif
#endif

附件

查看动态库中的符号表

nm libxxx.so |grep [函数名]

备注: t表示符号是本地符号,T表示符号是全局符号

 

posted on 2023-09-20 11:48  寒魔影  阅读(510)  评论(0编辑  收藏  举报

导航