如何创建与 pthreads 和 libstdc 静态链接的共享对象++ 在 Linux/gcc 上？

Question

如何在 Linux/gcc 上创建与 pthreads 和 libstdc++ 静态链接的共享对象？

Answer 1

在我按照描述回答您的问题之前，我会注意到，您最终想要实现的目标并不完全清楚，并且可能有更好的解决方案来解决您的问题。

也就是说 - 尝试执行您所描述的操作有两个主要问题：

1. 一个是，您需要将 libpthread 和 libstdc++ 分解为它们的对象文件是用. 这是因为ELF二进制文件（在Linux上使用）有两个级别的“运行时”库加载 - 即使可执行文件是静态链接的，加载器也必须在执行时加载二进制文件中的静态链接库，并映射正确的内存地址。 这是在动态加载的库（共享对象）并映射到共享内存的共享链接之前完成的。 因此，共享对象不能与此类库静态链接，因为在加载对象时，所有静态链接库都已加载。 这是静态库和普通目标文件链接之间的一个区别 - 静态库不仅像任何目标文件一样粘合到可执行文件中，而且仍然包含加载时引用的单独表。 （我相信这与 MS-DOS 和经典 Windows 中简单得多的静态库 .LIB 文件形成鲜明对比，但可能比我记得的要多） >.

   当然，您实际上不必分解libpthread和libstdc++，您可以只使用构建它们时生成的目标文件。 不过，收集它们可能有点困难（查找这些库的最终 Makefile 规则引用的对象）。 并且您必须直接使用 ld 而不是 gcc/g++ 进行链接，以避免与动态版本链接。

2. 第二个问题是必然的。 如果您执行上述操作，您肯定会拥有您要求构建的共享对象/动态库。 但是，它不会很有用，因为一旦您尝试将使用这些 libpthread/libstdc++ （后者是任何 C++ 程序）的常规可执行文件与此共享对象链接起来，它将因符号冲突而失败 - 您链接共享对象的静态 libpthread/libstdc++ 对象的符号将与标准 libpthread< 中的符号发生冲突/code>/libstdc++ 由该可执行文件使用，无论它是与标准库动态还是静态链接。

   您当然可以尝试隐藏共享库使用的 libstdc++/libpthread 的静态对象中的所有符号，以某种方式将它们设为私有，或者链接时自动重命名它们，这样就不会发生冲突。 然而，即使你让它工作，你也会在运行时发现一些不想要的结果，因为 libstdc++/libpthread 在全局变量和结构中保留了相当多的状态，现在你们将拥有重复的文件，并且彼此不知道对方。 这将导致这些全局数据与底层操作系统状态（例如文件描述符和内存边界）之间不一致（可能还有标准 C 库中的一些值，例如 libstdc++ 的 errno >，以及 libpthread 的信号处理程序和计时器。

为了避免过于宽泛的解释，我将添加一条评论：有时想要静态链接可能有合理的理由。甚至像 libstdc++ 甚至 libc 这样的基本库，即使对于最近的系统和这些库的版本来说它变得有点困难（由于与加载器和使用的特殊链接器技巧），这是绝对可能的 - 我做了几次，并且知道在其他情况下它仍然完成。在这种情况下，您需要静态链接整个可执行文件，与标准库的静态链接与其他对象的动态链接通常是不可行的。

---

编辑：我忘记提及但必须考虑的一个问题是 C++ 特定的。 不幸的是，C++ 的设计不能很好地与对象链接和加载的经典模型（在 Unix 和其他系统上使用）配合使用。 这使得 C++ 中的共享库不能真正实现应有的可移植性，因为许多内容（例如类型信息和模板）在对象之间没有清晰地分离（通常在编译时从标头中与许多实际的库代码一起获取） ）。 由于这个原因，libstdc++ 与 GCC 紧密耦合，并且使用一个版本的 g++ 编译的代码通常只能与此中的 libstdc++ 一起使用（或非常相似的）g++ 版本。 如果您尝试在使用 GCC 3 构建的系统上使用任何重要的库来使用 GCC 4 构建程序，您肯定会注意到，这不仅仅是 libstdc++。 如果您想要这样做的原因是试图确保您的共享对象始终与它所构建的特定版本的 libstdc++ 和 libpthread 链接，则这不会因为使用不同/不兼容的 libstdc++ 的程序也会使用不兼容的 C++ 编译器或 g++ 版本构建，因此无论如何都无法与您的共享对象链接，除了实际的 libstdc++ 冲突。

如果您想知道“为什么不把这做得更简单一些？”，那么一个值得深思的普遍思考：C++ 可以很好地与动态/共享库配合使用（意味着跨编译器的兼容性，以及替换动态库的能力）具有兼容接口的另一个版本的库，而无需重建使用它的所有内容），不仅需要编译器标准化，而且在操作系统加载器级别，对象和库文件的结构和接口以及链接器的工作都需要显着扩展，超出了常见操作系统（Microsoft Windows、基于 Mach 的系统和 NeXTStep 相关系统，例如 Mac OS、VMS 相关系统和一些大型机系统）上使用的相对简单的 Unix 经典）今天本地构建的代码。 链接器和动态加载器需要了解诸如模板和类型之类的事情，在某种程度上具有小型编译器的功能，以实际使库的代码适应给定的类型 - 并且（< em>此处的个人主观观察）似乎高级中间代码（连同高级语言和即时编译）正在更快地流行起来，并且可能比此类扩展更快地标准化。本机对象格式和链接器。

Answer 2

您在单独的评论中提到您正在尝试将 C++ 库移植到嵌入式设备。 （我在这里添加一个新答案，而不是在这里编辑我的原始答案，因为我认为对这个原始问题感兴趣的其他 StackOverflow 用户可能仍然对其上下文中的答案感兴趣）

• 显然，取决于关于你的嵌入式系统的精简程度（我没有太多嵌入式Linux经验，所以我不确定最有可能的是什么），你当然可以在上面安装共享的libstdc++并且动态链接所有内容，就像您在其他情况下所做的那样。

• 如果动态链接 libstdc++ 对您不利或无法在您的系统上工作（嵌入式系统有许多不同级别，人们无法知道），并且您需要链接到static libstdc++，那么正如我所说，您唯一真正的选择是使用该库与它和 libstdc++ 静态链接可执行文件。 您提到将库移植到嵌入式设备，但如果这是为了在您在设备上编写或构建的某些代码中使用它，并且您不介意静态 libstdc++，那么静态链接所有内容（除了libc）可能没问题。

• 如果libstdc++的大小是一个问题，并且您发现您的库实际上只使用了其接口的一小部分，那么我仍然建议首先尝试确定您需要的实际空间通过仅链接您需要的部分来保存。 它可能重要也可能不重要，我从来没有深入研究过 libstdc++ 并且我怀疑它有很多内部依赖项，所以虽然您肯定不需要某些接口，但您可能会也可能不会仍然取决于其内部的很大一部分 - 我不知道也没有尝试，但它可能会让你感到惊讶。 您可以通过将使用该库的二进制文件与它和 libstdc++ 的静态构建链接起来（当然，不要忘记剥离二进制文件），并将生成的可执行文件的大小与与库和 libstdc++ 的完整 (stripped) 共享对象动态链接在一起的 (stripped) 可执行文件的总大小。< /p>

  如果您发现大小差异很大，但又不想静态链接所有内容，则可以尝试通过重建 libstdc++ 来减小它的大小，而无需某些您知道不需要的部分（其中的某些部分有配置时选项，您也可以尝试在最终创建libstdc++.so时删除一些独立对象。有一些工具可以优化库的大小 -搜索网络（我记得来自一家名为 MontaVista 的公司，但现在在他们的网站上看不到它，还有其他一些）。

需要考虑一些想法和建议：

您提到您使用 uClibc，我自己从未摆弄过它（我对嵌入式编程的经验要原始得多，主要涉及嵌入式处理器的汇编编程和使用最小嵌入式库的交叉编译），我假设您检查了这一点，并且我知道 uClibc 旨在成为一个轻量级但相当完整的标准 C 库，但是不要忘记，C++ 代码很难独立于 C 库，而 g++ 和 libstdc++ 依赖于一些微妙的东西（我记得 libc 的问题> 在某些专有的 Unix 版本上），所以我不会只是假设 g++ 或 GNU libstdc++ 实际上可以在没有尝试的情况下与 uClibc 一起工作 - 我不这样做我不记得在 uClibc 页面中看到过它。

此外，如果这是一个嵌入式系统，请考虑其性能、计算能力、整体复杂性以及时序/简单性/可靠性要求。 考虑到所涉及的复杂性，并考虑在您的嵌入式系统中使用 C++ 和线程是否合适，如果系统中没有其他东西使用它们，是否值得为该库引入它们。 可能是，我不知道我无法告诉的库或系统（同样，嵌入式系统现在范围如此广泛）。

在这种情况下，我偶然发现了一个快速链接来寻找 uClibc - 如果您正在使用 uClibc 开发嵌入式系统，并且想要使用 C++ 代码关于它——看看uClibc++。 我不知道你需要多少标准的 C++ 东西并且它已经支持，而且它似乎是一个正在进行的项目，所以不清楚它是否已经处于对你来说足够好的状态，但假设你的工作也在对于您的嵌入式工作来说，它仍然是 GCC 的 libstdc++ 的一个很好的替代品。

Answer 3

我认为这个人很好地解释了为什么这不会使感觉。 使用共享对象但使用不同 libstdc++ 的 C++ 代码可以正常链接，但无法工作。