[linux] Linking against an old version of libc to provide greater application coverage



Answers

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:

  1. Using .symver to obtain the ref to memcpy@GLIBC_2.2.5.

  2. Write my own __wrap_memcpy function which just calls memcpy@GLIBC_2.2.5 directly.

  3. 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

Question

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.




Related