我可以为所有 Linux 编译器使用一个 Linux .so 吗？答案

【问题标题】：Can I use one Linux .so for all Linux compilers?我可以为所有 Linux 编译器使用一个 Linux .so 吗？
【发布时间】：2014-03-14 10:37:38
【问题描述】：

我们需要将一个闭源 C 库集成到我们的项目中。对方可以按照我们需要的任何模式编译库，但是我们支持很多不同的Windows和Linux编译器。

我知道 DLL 将与所有主要的 Windows 编译器兼容，因此我们只能为 Windows 使用一个库。但我对 Linux 动态库 (.so) 并不熟悉。它们是否以类似的方式在所有 Linux 环境中兼容？

谢谢

【问题讨论】：

如果 DLL 包含任何 C++ 导出，则它不会在 Windows 上的编译器之间兼容 - 仅当它包含以兼容格式（例如 extern "C"）的导出时才会如此。
纯C库。（更新了标签，虽然我们的项目是 C++）
“我知道 DLL 将与所有主要的 Windows 编译器兼容，因此我们只能为 Windows 使用一个库。” - 先试试。我知道——“使用不同编译器创建的对象文件和静态库，甚至是使用同一编译器的显着不同版本创建的，通常无法链接在一起。（来源mingw.org/wiki/MixingCompilers）
@SChepurin “DLL 略有不同。有时您可以将使用一种编译器构建的 DLL 链接到使用另一种编译器编译的应用程序。”我们可以做到。
根据经验，创建适用于不同发行版和版本的共享库和二进制文件需要付出相当大的努力。您通常会得到一个共享库，它需要跨发行版不兼容的运行时库/版本/符号。如果您只使用 libc，并在足够旧的 distro/glibc 版本上创建共享库，那么您可能会有机会。

标签： c linux dll

【解决方案1】：

您可能会遇到一些问题。已链接（和编译）共享库 libotherparty.so 的 GNU libc 版本。

您当然需要知道 libc 的版本，并且您可能需要该方提供二进制库的多个变体。

我强烈建议阅读 Drepper 的论文：How To Write Shared Libraries。另请参阅 this question 和 Levine 的 linker & loader 书籍。

如果是 C 代码，编译器无关紧要。更重要的是ABI。还可以了解symbol versioning。

做好遇到麻烦的准备。

^{您将通过经验了解到免费软件更可取。}

【讨论】：

您好，感谢您的回答。 Linux 菜鸟在这里。回复：第一句话。我可以让他们链接到任何必要的 GNU libc。我应该告诉他们什么以获得最大的兼容性？回复：第二句话。我需要哪些变体？我只想要 32 位 .so 和 64 位 .so 库，我可以在任何带有 gcc 的 Linux 发行版上使用。谢谢。

【解决方案2】：

如果函数接口预计会发生变化（C++ 公共/受保护的类定义）、库中包含更多或更少的函数、函数原型发生变化（返回数据类型（int、const int, ...) 或参数列表更改）或数据类型更改（对象定义：类数据成员、继承、虚函数...）。

可以在创建共享库时指定库版本。如果希望更新库，则应指定库版本。这对于动态链接的共享对象库尤其重要。这也避免了 Microsoft“DLL 地狱”的库冲突问题，其中更改标准库的系统升级会破坏需要旧版本的共享对象函数的旧应用程序。

版本控制也发生在 GNU C/C++ 库中。这通常会使使用一个版本的 GNU 工具编译的二进制文件与使用其他版本编译的二进制文件不兼容，除非这些版本也驻留在系统上。由于版本控制，同一库的多个版本可以驻留在同一系统上。库的版本包含在符号名称中，因此链接器知道要链接哪个版本。

可以查看使用的符号版本：nm csub1.o

00000000 T ctest1

默认情况下，目标代码中没有指定版本。

有一个 GNU C/C++ 编译器标志明确处理符号版本控制。使用标志指定在编译时使用的版本脚本：--version-script=your-version-script-file

注意：这仅在创建共享库时有用。假设程序员知道静态链接时要链接哪些库。运行时链接允许库不兼容。

关于 ABI 兼容性，还请查看 here

【讨论】：