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

Question

我有一个可执行文件,几乎只依赖于libc.ldd的输出是:

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上运行此可执行文件有多安全？具体来说,在Ubuntu和Debian机器上运行是否安全eglibc？我编译的可执行文件似乎在12.04 LTS上正常运行但是我可以相信这没有微妙的错误并且还运行在这些发行版的其他版本上吗？

Answer 1

EGLIBC被设计为与GLIB兼容的API和ABI,正如您在其功能页面中所读到的那样,只要您使用它的默认配置(如Debian版本),您就不应该有任何问题 - 即您不是使用一些功能少于GLIBC的限制版本.

特别是,你可以阅读Debian切换到EGLIBC的公告.请记住,如果Debian不能完全与GLIBC兼容,那么从Debian切换到EGLIBC是不合理的,因为它可能会破坏遗留的二进制文件或者只是来自Debian存储库的软件.

如果您使用的是有限版本的EGLIBC,除非您使用从库中删除的某些功能,否则不应该有问题.例如,使用GLIBC编译的二进制文件应该可以正常使用没有套接字的EGLIBC版本,只要它不使用它们即可.

Answer 2

@javidcf 是正确的，因为eglibc 和glibc 是ABI 兼容的，因为一般意义上，在eglibc 上运行使用glibc 编译的东西不应该有问题。

但是，您可能会遇到与 glibc 与 eglibc 无关的问题，而是与 glibc 版本偏差相关的问题。某些 glibc 函数在其末尾标有版本（例如通过 nm 查看或通过在二进制文件上运行字符串并 grep 查找 GLIBC 时的“printf@@GLIBC_2.2.5”）。我相信这些代表了运行生成的二进制文件的最低 glibc 版本要求。简单的程序可能很少（或没有）这些类型的函数。复杂的程序可能有多种要求。这是在 Ubuntu 14.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

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

这样做的结果是，在旧发行版上编译的二进制文件很有可能在新发行版上运行。但是，在较新的发行版上针对较新的 glibc 编译的二进制文件可能会使用标有更高最低要求的较新版本的函数，因此可能无法在较旧的系统上运行。例如，您的 CentOS 6 二进制文件可能无法在 CentOS 5 或 Ubuntu 10.04 上运行；但可能在 CentOS 7 和 Ubuntu 12.04/14.04 上运行良好。

如果您想要（更好的机会）真正可移植的二进制文件，静态链接是更好的选择。