Linking to older GLIBC symbols

[Bob Rossi <bob at brasko dot net>]

Hi,

I'm building an application that I distribute on Linux. My goal is
for it to work on as many distros as possible.

I think I've got everything figured out, accept for libc.
The goal is to ship an executable that uses a maximum GLIBC version,
pretend I want to target GLIBC version symbols of GLIBC_2.2.3.

The most popular answer I can find is, go build on the oldest
platform you want to support, and ship that executable. This
answer is pretty horrible. It requires me to rebuild a modern
binutils/gmp/mpfr,gcc,git,bison, etc on that old machine to get
my software to build. It accomplishes the goal of using only
those lower versioned GLIBC symbols, but at great expense.

Another approach would be to try to use the current GLIBC
on your modern development machine, but pull in the older
symbols manually.  I read an article here,
  http://www.trevorpounds.com/blog/?tag=symbol-versioning
descripting how to do that. However, I'm thinking that won't work
if a library I'm using does a test to see if a function
is available in libc, and then uses it, and that symbol was
never defined at or before GLIBC_2.2.3. My executable would
want the symbol, and I wouldn't be able to choose an old one,
those forcing me to have the GLIBC symbols that are above
my targeted goal. Can you trick glibc/gcc into making those
higher versioned GLIBC symbols invisible?

The final solution I came accross was to have a chroot environment
on the modern development machine and then build an older glibc.
If I did that, I'm thinking I'd basically have to build
my entire tool chain, is that correct? and that certainly
doesn't sound fun.

Is there any easy way to use a modern glibc/linux distro
and link against versions at or before a certain GLIBC
version to make distributing the binaries easy?

Thanks,
Bob