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

LinuxLinkerLibc

Linux Problem Overview


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?

Linux Solutions


Solution 1 - Linux

Work out which symbols in your executable are creating the dependency on the undesired version of glibc.

$ objdump -p myprog
...
Version References:
  required from libc.so.6:
    0x09691972 0x00 05 GLIBC_2.3
    0x09691a75 0x00 03 GLIBC_2.2.5

$ objdump -T myprog | fgrep GLIBC_2.3
0000000000000000      DF *UND*	0000000000000000  GLIBC_2.3   realpath

Look within the depended-upon library to see if there are any symbols in older versions that you can link against:

$ objdump -T /lib/libc.so.6 | grep -w realpath
0000000000105d90 g    DF .text	0000000000000021 (GLIBC_2.2.5) realpath
000000000003e7b0 g    DF .text	00000000000004bf  GLIBC_2.3   realpath

We're in luck!

Request the version from GLIBC_2.2.5 in your code:

#include <limits.h>
#include <stdlib.h>

__asm__(".symver realpath,realpath@GLIBC_2.2.5");

int main () {
    realpath ("foo", "bar");
}

Observe that GLIBC_2.3 is no longer needed:

$ objdump -p myprog
...
Version References:
  required from libc.so.6:
    0x09691a75 0x00 02 GLIBC_2.2.5

$ objdump -T myprog | grep realpath
0000000000000000      DF *UND*	0000000000000000  GLIBC_2.2.5 realpath

For further information, see <http://web.archive.org/web/20160107032111/http://www.trevorpounds.com/blog/?p=103>;.

Solution 2 - Linux

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

Solution 3 - Linux

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 system libstdc++.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 the printf ... redeff line.

#!/bin/bash
maxver=2.9
headerf=${1:-glibc.h}
set -e
for lib in libc.so.6 libm.so.6 libpthread.so.0 libdl.so.2 libresolv.so.2 librt.so.1; do
objdump -T /usr/lib/$lib
done | awk -v maxver=${maxver} -vheaderf=${headerf} -vredeff=${headerf}.redef -f <(cat <<'EOF'
BEGIN {
split(maxver, ver, /\./)
limit_ver = ver[1] * 10000 + ver[2]*100 + ver[3]
}
/GLIBC_/ {
gsub(/\(|\)/, "",$(NF-1))
split($(NF-1), ver, /GLIBC_|\./)
vers = ver[2] * 10000 + ver[3]*100 + ver[4]
if (vers > 0) {
	if (symvertext[$(NF)] != $(NF-1))
		count[$(NF)]++
	if (vers <= limit_ver && vers > symvers[$(NF)]) {
		symvers[$(NF)] = vers
		symvertext[$(NF)] = $(NF-1)
	}
}
}
END {
for (s in symvers) {
	if (count[s] > 1) {
		printf("__asm__(\".symver %s,%s@%s\");\n", s, s, symvertext[s]) > headerf
		printf("%s %s@%s\n", s, s, symvertext[s]) > redeff
	}
}
}
EOF
)
sort ${headerf} -o ${headerf}
objcopy --redefine-syms=${headerf}.redef /usr/lib/libstdc++.a libstdc++.a
rm ${headerf}.redef

Solution 4 - Linux

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.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionGearoid MurphyView Question on Stackoverflow
Solution 1 - LinuxSam MorrisView Answer on Stackoverflow
Solution 2 - Linuxnicky_zsView Answer on Stackoverflow
Solution 3 - LinuxpatstewView Answer on Stackoverflow
Solution 4 - LinuxDouglas LeederView Answer on Stackoverflow