Dangers of compiling with GNU Libc and running on eglibc in Linux?

Question

I have an executable which pretty much only depends on libc. the output of ldd is:

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)

I've compiled this on and old CentOS 6. running /lib64/libc.so.6 says:

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

How safe is it to run this executable on any other flavor of linux? Specifically, is it safe to run on Ubuntu and Debian machines which have eglibc? The executable I compiled seem to be running fine on 12.04 LTS but can I trust this to not have subtle bugs and to also run on other versions of these distros?

Answer 1

EGLIBC was designed to be API and ABI compatible with GLIB, as you may have read in its features page, so you should not have any problem as long as you use the default configuration of it (like the Debian version) - i.e. you are not using some limited version with less features than GLIBC.

In particular, you can read the announcement of Debian switching to EGLIBC. Keep in mind that it would not have been reasonable from Debian switching to EGLIBC if it wasn't fully ABI compatible with GLIBC, because it could have broken legacy binaries or just software not coming from the Debian repositories.

If you are using a limited version of EGLIBC, you should not have problem unless you use some of the features removed from the library. For example, a binary compiled with GLIBC should work fine with a version of EGLIBC without sockets, as long as it doesn't use them.

Answer 2

@javidcf is correct in that eglibc and glibc are ABI compatible, in that you shouldn't have an issue running something compiles with glibc on eglibc in the general sense.

However, you may run into issues that aren't related to glibc vs. eglibc, but instead related to glibc version skew. Certain glibc functions are tagged with a version at the end of them (such as 'printf@@GLIBC_2.2.5', when viewed by nm, or by running strings on the binary and grepping for GLIBC). I believe these represent a kind of minimum glibc version requirement to run the resulting binary. Simple programs might have few (or none) of these type functions. Complex programs may have multiple requirements. Here's the result of running strings on my firefox binary on Ubuntu 14.04:

$ 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

This means I would need at least version 2.17 of the glibc library to resolve the symbols needed to run this program.

The upshot of this is that a binary compiled on older distributions has a good chance of working on a newer one; but a binary compiled on a newer distro, against a newer glibc, which may use newer versions of functions that will be tagged with higher minimum requirements, will likely not work on older systems. For example, your CentOS 6 binary might not run on CentOS 5, or Ubuntu 10.04; but might run fine on CentOS 7 and Ubuntu 12.04/14.04.

Static linking is a better option if you want a (better chance at a) truly portable binary.