gcc: Reduce libc required version

Question

I am trying to run a newly compiled binary on some oldish 32bits RedHat distribution.
The binary is compiled C (not++) on a CentOS 32bits VM running libc v2.12.

Red

Answer 1

An untested possible solution

What is "error while loading shared libraries: requires glibc 2.5 or later dynamic linker"?

The cause of this error is the dynamic binary (or one of its dependent shared libraries) you want to run only has .gnu.hash section, but the ld.so on the target machine is too old to recognize .gnu.hash; it only recognizes the old-school .hash section.

This usually happens when the dynamic binary in question is built using newer version of GCC. The solution is to recompile the code with either -static compiler command-line option (to create a static binary), or the following option:

-Wl,--hash-style=both

This tells the link editor ld to create both .gnu.hash and .hash sections.

According to ld documentation here, the old-school .hash section is the default, but the compiler can override it. For example, the GCC (which is version 4.1.2) on RHEL (Red Hat Enterprise Linux) Server release 5.5 has this line:

$ gcc -dumpspecs
....
*link:
%{!static:--eh-frame-hdr} %{!m32:-m elf_x86_64} %{m32:-m elf_i386} --hash-style=gnu   %{shared:-shared}   ....
                                                                   ^^^^^^^^^^^^^^^^
...

For more information, see here.

Answer 2

Ok then, trying to find some balance between elegance and brute force, I downloaded a VM matching the target kernel version, hence fixing library issues.
The whole thing (download + yum install gcc) took less than 30 minutes.

References: Virtual machines, Kernel Version Mapping Table

Answer 3

I already had the same problem, trying to compile a little tool (I wrote) for an old machine for which I had not compiler. I compiled it on an up to date machine, and the binary required at least GLIBC 2.14 in order to run.

By making a dump of the binary (with xxd), I found this :

....
5f64 736f 5f68 616e 646c 6500 6d65 6d63  _dso_handle.memc
7079 4040 474c 4942 435f 322e 3134 005f  py@@GLIBC_2.14._
....

So I replaced the memcpy calls in my code by a call to an home-made memcpy, and the dependency with the glibc 2.14 magically disappeared.

I'm sorry I can't really explain why it worked, or I can't explain why it didn't work before the modification.

Hope it helped !