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.

RedHat complains about libc version:

error while loading shared libraries: requires glibc 2.5 or later dynamic linker

Since my program is rather simplistic, It is most likely not using anything new from libc.

Is there a way to reduce libc version requirement

This answer might help http://stackoverflow.com/questions/2856438/how-can-i-link-to-a-specific-glibc-version — user1202136, Aug 22 '12 at 14:38

score 25 · Accepted Answer · edited Jan 21 '17 at 15:15

25

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.

edited Jan 21 '17 at 15:15

123

8,733
14
57
99

answered Aug 22 '12 at 14:43

Michael Burr

333,147
50
533
760

Unfortunately the -Wl flags is not digested by my gcc -m32 – MonoThreaded Aug 23 '12 at 08:43
1

@AknownImous: what is the error you get? The 'argument to the `-Wl,` option is just passed to the linker - are you linking using `gcc` or are you invoking `ld` or some other linker directly? Also, note that there cannot be a space in the `-Wl,--hash-style=both` option. – Michael Burr Aug 23 '12 at 20:09
gcc is complaining about "unrecognized command line option -Wl". I am only using gcc. – MonoThreaded Aug 23 '12 at 21:09
@AknownImous: Can you copy/paste your gcc command line and the output of `gcc -v`? The `-Wl` option is documented even for GCC 2.95.3 which was released in 2001 so I'm surprised your gcc has trouble with it. – Michael Burr Aug 23 '12 at 21:34
1

In 2017 this has also worked for me. My web hosting company web server, which seems to be Centos, happily runs a compiled C binary I built on Debian in 2006 but refused to run one rebuilt now on Fedora 17. Following this answer, compared old and new using "readelf -a" on each. Sure enough under "Section Headers:" and elsewhere, the new one has " [ 4] .gnu.hash GNU_HASH 08048".... whereas the old one has " [ 3] .hash HASH 08048128 "...So I added flags "-Wl,--hash-style=sysv" to gcc link line and all is good. – Stephen Hewitt Sep 05 '17 at 11:09
Confirming; I see this error when compiling with gcc 6.3.0 20170205 on `4.6.0-kali1-686 #1 SMP Debian 4.6.4-1kali1 (2016-07-21) i686 GNU/Linux` for CentOS 4.8. Propose solution works for me. – kidmose Oct 25 '17 at 08:13
I used this command `-Wl,--hash-style=both` and it resolved my issues. Thank you. – Fallenreaper Dec 30 '17 at 17:25
Everyone pay attention, it is: `-Wl,--hash-style=both` (with no space between `-Wl,` and `--hash-style=both` ) – user1438233 Dec 22 '19 at 10:57

score 5 · Answer 2 · answered Aug 22 '12 at 14:58

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 !

Yes I'm agree, but in that case, the code is very small, and memcpy is called only 3 times in my code — phsym, Aug 23 '12 at 09:14

score 3 · Answer 3 · answered Aug 23 '12 at 08:50

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

gcc: Reduce libc required version

3 Answers3

Linked