我目前正在为一大堆代码更新构建系统，其中恰好包含一个 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 安装或从源代码构建它。
我试图处理同样的问题（这导致我找到了这个问题），经过一系列研究得出了明确的结论，不，你没有错过任何东西，除了编译自己的 g++，没有办法解决这个问题。在 gcc-help 邮件列表中查看最近的这个问题：
http://gcc.gnu.org/ml/gcc-help/2013-01/msg00008.html
我比较了 gcc 来源，发现你可以高达 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
如果你四处搜索，你会发现人们出于各种原因在其他列表中抱怨它，但我想它会留下来。