The dangers of compiling with GNU Libc and working on eglibc on Linux?

Question

I have an executable that is heavily dependent only on libc. ldd output:

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 compiled this and the 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 for any other linux flavor? In particular, is it safe to work on Ubuntu and Debian machines that have eglibc ? The executable that I compiled seems to work fine on 12.04 LTS, but can I trust this so that it doesn't have subtle errors, and also to run other versions of these distributions?

Answer 1

@javidcf is true that eglibc and glibc are ABI compatible, since you should have no trouble running compilation from glibc to eglibc in a general sense.

However, you may encounter problems that are not related to glibc vs. eglibc, but instead are associated with a skew version of glibc. Some glibc functions are marked with a version at the end of them (for example, 'printf @@ GLIBC_2.2.5', if you look at nm, or by running strings in binary and grepping for GLIBC). I believe that they are the minimum requirement for the glibc version to run the resulting binary. Simple programs may have few (or not) these type functions. Comprehensive programs may have several requirements. Here's the result of running lines 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 that I will need at least version 2.17 of the glibc library to resolve the characters needed to run this program.

As a result, it turns out that a binary file compiled on earlier distributions has good chances to work on a newer one; but the binary compiled in the newer distribution, against the newer glibc, which can use newer versions of functions that will be marked with higher minimum requirements, most likely will not work on older systems. For example, your CentOS 6 binary may not work on CentOS 5 or Ubuntu 10.04; but it may work fine on CentOS 7 and Ubuntu 12.04 / 14.04.

Static binding is the best option if you want (the best chance of) a truly portable binary.

Answer 2

EGLIBC was designed as an API and ABI compatible with GLIB, as you may have read it on the page, so you should not have any problems while using the default configuration (e.g. Debian version), i.e. you are not using a limited version with less features than GLIBC.

In particular, you can read the Debian transition announcement to EGLIBC . Keep in mind that it would be unreasonable if Debian switched to EGLIBC, if it were not fully compatible with ABI with GLIBC, because it could break obsolete binaries or just software not included in the Debian repository.

If you are using a limited version of EGLIBC, you should have no problem if you are not using some of the functions removed from the library. For example, a binary compiled with GLIBC should work fine with a version of EGLIBC without sockets if it does not use them.