linux - 将静态库链接到共享库时是否应该隐藏符号?

标签 linux gcc linker static-linking dynamic-linking

当您编写共享库时,通常建议隐藏所有内部符号以减少动态链接时间,通常使用链接描述文件或 -fvisibility 选项。

在我的例子中,共享库与其他两种类型的库链接:

  • 内部静态库
  • 第三方静态库(例如 libuv)

所有这些都使用 -Wl,--whole-archive 选项链接到共享库中,因此生成的共享库是自给自足的,并且仅链接到 stdlib。

来自内部静态库的所有符号都被隐藏,因为它们不是公共(public) API 的一部分。

问题是从第三方静态库中隐藏符号的优缺点是什么?是否有任何最佳实践和已知的陷阱?一方面,它们不是我图书馆的公共(public) API 的一部分。另一方面,它们是第三方库的公共(public) API 的一部分。

我想当用户想要链接到同一个第三方库的另一个版本时就会出现问题。理论上隐藏它的符号可能会解决问题,但感觉在实践中可能会导致一些新的意想不到的问题。

最佳答案

在我看来,您应该隐藏所有不属于您的 API 的符号。似乎您还需要一个选项 --exclude-libs,ALL 将第三方静态库符号转换为隐藏符号。我不知道该解决方案的任何缺点,它加速了动态链接器,也没有看到与另一个库版本进一步静态链接的任何缺点.. 因为它的静态链接不是动态链接(热交换等)。

关于linux - 将静态库链接到共享库时是否应该隐藏符号?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/46379201/

相关文章:

c++ - LNK2022 使用/clr 时出错

linux - 允许用户 ^C 子进程而不是整个脚本

java - 为什么 Bluecove 需要安装 libbluetooth-dev 软件包才能运行

c - minGW 下 _rotl 性能较差

c++ - C++中的虚拟继承和统一初始化

c# - 在 x64 上编译 OLEDB 依赖的可执行文件

linux - NASM Linux 共享对象错误 : Relocation R_X86_64_32S against '.data'

c - (((long)*(ptr)) << 1) >> 1;

linux - 软件能否包装 gzip/gunzip 以保留文件所有权?

gcc - 相对路径与使用 $ORIGIN 作为 RPATH 的区别