我有一个可执行文件,几乎只依赖于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上运行此可执行文件有多安全？具体来说,在具有eglibc的Ubuntu和Debian机器上运行是否安全？我编译的可执行文件似乎在12.04 LTS上正常运行,但是我可以相信这没有微妙的错误,并且还运行在这些发行版的其他版本上吗？
解决方法
@javidcf是正确的,因为eglibc和glibc是ABI兼容的,因为在一般意义上你不应该在eglibc上运行与glibc编译的东西.
但是,您可能会遇到与glibc与eglibc无关的问题,而是与glibc版本偏斜相关.某些glibc函数标记有它们末尾的版本(例如’printf @@ GLIBC_2.2.5′,当用nm查看时,或者通过在二进制文件上运行字符串和grepping for GLIBC).我相信这些代表了运行生成的二进制文件的一种最低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上运行良好.
