我目前正在为大量代码更新构建系统，这恰好包括一个Linux C ++项目。如果所有这些开发人员都可以在使用他们自己的想法进行攻击时运行构建会很好，所以我正在研究是否有可能在模糊的现代Linux系统上构建它，尽管目标系统是2.6.18。
通过'模糊的现代'，我估计像GCC 4.5+这样的东西，过去一两年的分布可能会附带。目前我通过静态编译来解决libstdc ++问题，并且通过使用快速的包装代码重新映射到旧版本的memcpy符号（等等），可以巧妙地解决任何glibc问题。到目前为止一切都很好。
我似乎无法完全弄清楚的一个问题是，.o文件中可执行文件中内置的某些符号是'u'类型，它是一个GNU唯一对象，是对EPF标准的扩展2.6 .18似乎根本没有认识到。这意味着可执行文件不会运行，因为它无法找到符号，尽管它们实际上存在（目标上的类型为'？'，来自'nm'）。
在编译G ++时，可以禁用GNU唯一对象，但这并不是最方便的解决方案。在编译代码时我看不到任何方法来禁用它（发行版gcc / g ++总是有这个选项），我想目标系统识别它的唯一方法就是更新ld-linux和内核。这几乎肯定不会发生。
我有没有找到禁用这些符号类型的选项？或许也有一些巧妙的方法，或者我缺少的东西？我开始怀疑它只需要在G ++ 4.1.x上编译，这将意味着从源代码开始安装或构建旧的Linux。
答案 0 :(得分：7)
我试图处理同样的问题（导致我发现这个问题）并且经过一系列的研究得出了明确的结论，不是，你没有遗漏任何东西，除了编译你的拥有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
如果你在周围搜索，你会发现有人因为各种原因在其他名单上抱怨过，但我想它会留下来。