linux - 海湾合作委员会/G++ : building without GNU unique object symbols for older Linux kernels

Question

我目前正在为一大堆代码更新构建系统，其中恰好包括一个 Linux C++ 项目。如果这里的所有开发人员都可以在根据自己的想法进行修改时运行一个构建，那就太好了，所以我正在研究是否有可能在模糊的现代 Linux 系统上构建它，尽管目标系统是 2.6.18。

通过“模糊现代”，我估计是 GCC 4.5+ 之类的东西，过去一两年的发行版可能会附带一些东西。目前，我通过静态编译来解决 libstdc++ 问题，并且通过使用一些快速的包装代码重新映射到旧版本的 memcpy 符号(等等)，可以巧妙地解决任何 glibc 问题。到目前为止一切顺利。

我似乎无法完全弄清楚的一个问题是，.o 文件中内置到可执行文件中的某些符号属于“u”类型，这是一个 GNU 独特的对象，是 ELF 标准的扩展，2.6 .18 似乎根本不认识。这意味着可执行文件将无法运行，因为它找不到符号，尽管它们实际上存在(只是目标上的类型“？”，来自“nm”)。

编译 G++ 时可以禁用 GNU 唯一对象，但这并不是最方便的解决方案。在编译代码时我看不到任何禁用它的方法(发行版 gcc/g++ 总是启用此选项)，我想让目标系统识别它的唯一方法是更新 ld-linux 和内核.这几乎肯定不会发生。

我还没有找到禁用这些符号类型的选项吗？或者也许有一些巧妙的方法可以解决这个问题，或者我缺少什么？我开始怀疑它只需要在 G++ 4.1.x 上编译，这意味着旧的 Linux 安装或从源代码构建。

Answer 1

我试图处理同样的问题(这让我找到了这个问题)，经过大量研究得出明确的结论，不，你没有遗漏任何东西，除了编译你的自己的g++。在 gcc-help 邮件列表中查看最近的这个问题:

http://gcc.gnu.org/ml/gcc-help/2013-01/msg00008.html

我比较了 gcc 源代码，发现你可以达到 stock 4.4，因为在 4.5 中添加了独特的符号。然而，在 RHEL/CentOS 6 上，它们默认为 4.4，但在其中修补了独特的符号支持，因此像往常一样，必须提防特定于发行版的 gcc 版本。对我来说，这是一个巨大的失败，因为它意味着在 RHEL 6 上编译的东西不能在 RHEL 5 上运行，即使是为 gcc 4.4 + RHEL 5 制作的 libstdc++ 副本也是如此。

顺便说一句，这是首次提出唯一符号支持的消息:

https://gcc.gnu.org/ml/gcc-patches/2009-07/msg01240.html

如果你四处搜索，你会发现人们出于各种原因在其他列表上提示它，但我想它会一直存在。