Linux binaries are usually dynamically linked to the core system library (libc). This keeps the memory footprint of the binary quite small but binaries which are dependent on the latest libraries will not run on older systems. Conversely, binaries linked to older libraries will run happily on the latest systems.
Therefore, in order to ensure our application has good coverage during distribution we need to figure out the oldest libc we can support and link our binary against that.
How should we determine the oldest version of libc we can link to?
glibc 2.2 is a pretty common minimum version. However finding a build platform for that version may be non-trivial.
Probably a better direction is to think about the oldest OS you want to support and build on that.
Work out which symbols in your executable are creating the dependency on the undesired version of glibc.
Look within the depended-upon library to see if there are any symbols in older versions that you can link against:
We're in luck!
Request the version from
GLIBC_2.2.5
in your code:Observe that GLIBC_2.3 is no longer needed:
For further information, see http://www.trevorpounds.com/blog/?p=103.
Unfortunately, @Sam's solution doesn't work well in my situation. But according to his way, I found my own way to solve that.
This is my situation:
I'm writing a C++ program using the Thrift framework(it's an RPC middleware). I prefer static link to dynamic link, so my program is linked to libthrift.a statically instead of libthrift.so. However, libthrift.a is dynamically linked to glibc, and since my libthrift.a is build on my system with glibc 2.15, my libthrift.a uses memcpy of version 2.14(memcpy@GLIBC_2.14) provided by glibc 2.15.
But the problem is that our server machines have only the glibc version 2.5 which has only memcpy@GLIBC_2.2.5. It is much lower than memcpy@GLIBC_2.14. So, of course, my server program can't run on those machines.
And I found this solusion:
Using .symver to obtain the ref to memcpy@GLIBC_2.2.5.
Write my own __wrap_memcpy function which just calls memcpy@GLIBC_2.2.5 directly.
When linking my program, add -Wl,--wrap=memcpy option to gcc/g++.
The code involved in steps 1 and 2 is here: https://gist.github.com/nicky-zs/7541169
To do this in a more automated fashion, you can use the following script to create a list of all the symbols that are newer in your GLIBC than in a given version (set on line 2). It creates a
glibc.h
file (filename set by the script argument) which contains all the necessary.symver
declarations. You can then add-include glibc.h
to your CFLAGS to make sure it gets picked up everywhere in your compilation.This is sufficient if you don't use any static libraries that were compiled without the above include. If you do, and you don't want to recompile, you can use
objcopy
to create a copy of the library with the symbols renamed to the old versions. The second to bottom line of the script creates a version of your systemlibstdc++.a
that will link against the old glibc symbols. Adding-L.
(or-Lpath/to/libstdc++.a/
) will make your program statically link libstdc++ without linking in a bunch of new symbols. If you don't need this, delete the last two lines and theprintf ... redeff
line.