将静态库链接到共享库（例如openmp）是一个好主意

Posted 2021-04-01

我正在linux系统上构建一个共享库，该库旨在用于将部署在服务器上的Docker中的项目中。这个共享库使用openmp。因此，我想知道它是否更好（或更便携）

1. openmp静态链接到我的共享库
2. 我应该在Docker中正确安装gcc以便找到openmp
3. 将openmp的.so与我的库一起分发

如果选项1是最好的，有人可以使用cmake提供正确的方法吗？

我在下面添加一些关于这个主题的文档：

• Are runtime libraries inherently dynamic libraries
• intelForum
• https://cmake.org/pipermail/cmake/2007-May/014347.html

答案

您通常无法将静态库链接到共享库。

因为静态库（lib*.a）不包含position-independent code（PIC），但共享库需要PIC（在实践中）。

（理论上，非PIC共享库可能是可能的;但它们将包含如此多的relocation，“共享”方面丢失，而dynamic linker将有很多工作。所以在实践中，每个共享库需要PIC才允许它的code segment [s]在各种过程中的不同地址进行mmap(2)-ed并仍保持共享状态）

阅读Drepper的How To Write Shared Libraries论文。

但是，您可以将共享库（例如libopenmp.so）链接到另一个库（您的共享库，请参阅this）。那么使用你的共享库的程序将需要libopenmp.so。

所以你可以做2或3，甚至打包你的库作为一个适当的.deb包（这将取决于libopenmpi2 Debian包）。

你可能想了解package management。

你应该更多地了解你的virtual address space的process。为此，使用proc(5)和pmap(1)。对于第一个例子，尝试cat /proc/self/maps和cat /proc/$$/maps。然后，如果您的进程有pid 1234，请尝试cat /proc/1234/maps和/或pmap 1234。然后，您将了解共享库是如何进行mmap(2)编辑的。

另一答案

即使您可以实现它，静态地将OpenMP运行时链接到另一个共享库也是一个坏主意。如果最终代码的某些其他组件也使用OpenMP，那么在此过程中最终会有两个不同的OpenMP运行时。当每个运行时创建自己的线程池并因此性能不佳时，这会快速导致超额预订。 （如果您的代码假定OpenMP关键部分可以保护它免受其他并行代码的影响，那么潜在的正确性失败......）

最简单的答案可能是您的第3个：使用您的代码发送相关OpenMP运行时共享库​​的副本。