GLIBC has extraordinary backward compatibility to ensure that each program runs with the versions of the symbols it was compiled against (see objdump -T on libc). If you really want to you can also choose to link against a specific version of a symbol.
If other libraries paid as much attention to library backward compatibility the world you be a lots nicer place (you could copy binaries around between distributions and they would work).
Posted Apr 1, 2012 1:54 UTC (Sun) by BenHutchings (subscriber, #37955)
[Link]
If you want a program to run on older versions of glibc, you need to use the old interface definitions and the old symbol versions. Just overriding the symbol versions will generally result in your program corrupting data or crashing.
A turning point for GNU libc
Posted Apr 5, 2012 8:34 UTC (Thu) by nix (subscriber, #2304)
[Link]
You'll also need the versions of libc_nonshared.a and libpthread_nonshared.a that belong to the version of glibc you're trying to use those versioned symbols from (this is one reason why arbitrary .o files are not safe to keep across glibc upgrades). All told it is sufficiently hard to make this work that it's not really worth bothering.
A turning point for GNU libc
Posted Apr 5, 2012 15:06 UTC (Thu) by khim (subscriber, #9252)
[Link]
Actually this is what LSB is doing and it works fine AFAICS.
A turning point for GNU libc
Posted Apr 8, 2012 11:21 UTC (Sun) by nix (subscriber, #2304)
[Link]
Yeah. I was talking about doing it by hand, yourself. :)