GCC/G ++：没有GNU唯一对象符号建设老版本的Linux内核

Question

我目前正在更新构建系统一大堆的代码，这恰好包括一个Linux C++项目。如果这里的所有开发人员都可以在构建自己的想法时进行构建，那么我会考虑是否可以在隐约现代的Linux系统上构建这个系统，尽管目标系统是2.6.18。

通过“隐约现代”我估计像GCC 4.5+的东西，在过去的一年或两年分布可能配。目前，我通过静态编译来解决libstdC++问题，并且任何glibc问题都可以通过重新映射到旧版本的memcpy符号（等等）和快速包装代码来巧妙地解决。到现在为止还挺好。

我似乎无法完全弄清楚的一个问题是，从.o文件构建到可执行文件中的某些符号的类型为'u'，它是GNU独特的对象，是ELF标准的扩展2.6.18似乎完全不承认。这意味着可执行文件不会运行，因为它找不到符号，尽管它们实际上存在（只是'nm'中目标'？'的类型）。编译g当

人们可以禁止使用GNU唯一对象++，但它并不完全是最方便的解决方案。编译代码时，我看不到任何方法禁用它（distro gcc/g ++总是有这个选项），我想想让目标系统识别它的唯一方法是更新ld-linux和内核。这几乎肯定不会发生。

有没有我还没有发现禁用这些符号类型的选项？或者也许有一些干净利落的方式，或者我错过了什么？我开始怀疑它只能在G ++ 4.1.x上编译，这将意味着一个旧的Linux安装或源代码编译。

Answer 1

我试图解决同样的问题（这使我发现了这个问题），并经过了一堆的研究来没有，你是不是缺少什么明确的结论，有没有办法解决这个除了编译你自己的g ++。请参阅GCC-帮助邮件列表上这个最近的问题：

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

我比较GCC的来源，发现你可以去高达4.4的股票，如独特的符号在4.5加入。然而，在RHEL/CentOS 6上，它们默认为4.4，但在其中修补了独特的符号支持，因此通常必须提防特定于分发版的gcc版本。对我来说，这是一个巨大的失望，因为它意味着在RHEL 5上编译的东西无法在RHEL 5上运行，即使是为gcc 4.4 + RHEL 5制作的libstdC++的副本。

下面是消息，其中唯一符号支持宣布，顺便说一句：

http://www.redhat.com/archives/posix-c++-wg/2009-August/msg00002.html

如果你搜索你周围就会发现，人们一直在抱怨它在其他列出了各种理由，但我想这是在这里停留。