用GNU Libc编译并在Linux中运行eglibc的危险？

Question

我有一个几乎只依赖libc的可执行文件。土地退化和干旱的产出是：

libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b53156b9000)
libutil.so.1 => /lib64/libutil.so.1 (0x00002b53158d5000)
librt.so.1 => /lib64/librt.so.1 (0x00002b5315ad8000)
libdl.so.2 => /lib64/libdl.so.2 (0x00002b5315ce2000)
libm.so.6 => /lib64/libm.so.6 (0x00002b5315ee6000)
libc.so.6 => /lib64/libc.so.6 (0x00002b5316169000)
/lib64/ld-linux-x86-64.so.2 (0x0000003a06600000)

我在以前的CentOS 6上编译了这个程序。运行/lib64/libc.so.6时说：

GNU C Library stable release version 2.5, by Roland McGrath et al.
...

在任何其他版本的linux上运行这个可执行文件有多安全？具体来说，在具有eglibc的Ubuntu和Debian机器上运行安全吗？我编译的可执行文件在12.04 LTS上似乎运行得很好，但我可以相信它没有细微的bug，也可以在这些发行版的其他版本上运行吗？

Answer 1

@javidcf是正确的，因为eglibc和glibc是ABI兼容的，因为在一般意义上，您不应该在eglibc上运行与glibc一起编译的东西。

但是，您可能会遇到与glibc与eglibc无关的问题，而是与glibc版本倾斜相关的问题。某些glibc函数在它们的末尾加上一个版本的标记(例如'printf@@GLIBC_2.2.5'，在nm中查看，或者在二进制文件上运行字符串，并对GLIBC表示祝贺)。我相信这些代表了运行结果二进制文件的一种最小的glibc版本要求。简单的程序可能很少(或没有)这些类型的函数。复杂的程序可能有多个需求。下面是在Ubuntu14.04上运行firefox二进制文件的字符串的结果：

$ strings /usr/lib/firefox/firefox | grep GLIBC
GLIBC_2.2.5
GLIBC_2.3
GLIBC_2.4
GLIBC_2.3.2
GLIBC_2.3.4
GLIBC_2.17
GLIBCXX_3.4

这意味着我至少需要2.17版本的glibc库来解析运行该程序所需的符号。

这样做的结果是，在旧发行版上编译的二进制代码很有可能在较新的发行版上进行编译；但是在较新的发行版上编译的二进制代码相对于较新的glibc版本(可能使用带有更高最低要求的更新函数版本)很可能无法在旧系统上工作。例如，您的CentOS 6二进制文件可能不在CentOS 5或Ubuntu10.04上运行，但在CentOS 7和Ubuntu12.04/14.04上可能运行良好。

静态链接是一个更好的选择，如果你想要一个真正的可移植二进制(更好的机会)。

Answer 2

EGLIBC被设计为与GLIB兼容的API和ABI，正如您在它的features page中所读过的那样，所以只要您使用它的默认配置(比如Debian版本)，您就不会有任何问题--也就是说，您不会使用一些功能比GLIBC更少的有限版本。

特别是，您可以阅读announcement of Debian switching to EGLIBC。请记住，如果Debian不完全兼容GLIBC，那么从Debian切换到EGLIBC是不合理的，因为它可能破坏了遗留二进制文件，或者只是来自Debian存储库的软件。

如果您使用的是有限版本的EGLIBC，那么除非您使用从库中删除的一些特性，否则不会出现问题。例如，使用GLIBC编译的二进制文件在没有套接字的EGLIBC版本中可以很好地工作，只要它不使用它们。