When I'm compiling my elf, it is "best practice" to make it link against the oldest version of glibc I can, so it will work both on new and old versions of glibc.
i.e. if I use realpath, which in readelf output of glibc we can see has both a GLIBC_2.0 version and a GLIBC_2.3 version, I want to use the old version so my ELF would work on glibc 2.0/1/2.
But the GLIBC_2.3 version was probably developed and upgraded since it was published, and I guess GLIBC_2.0 version hasn't changed since glibc 2.3 has been published. So I guess I want my elf to use GLIBC_2.3 version when it is present, and when not, to fallback to the GLIBC_2.0 version.
Is is possible? Or what don't I understand?
That's not possible without massive further ado.
Assume that libc is nothing more than a regular library. Now, the linking process that happens between compilation and the final ELF binary involves resolving the used symbols. Glibc symbols are versioned since uhh... forever, I think, so you can't use the same compiled code for both versions of the library. What you'd need to do is having two versions of your program, and run the right one, depending on what version of glibc is available.
The problem here is that almost any such functionality would require using glibc...
Anyway, you seem to be working around bugs in different glibc implementations. That sounds awful, and I don't envy you, especially since you don't seem to know which version of glibc your program is going to find. The right approach for programs that can't rely on a specific library being available is static linking, so that all the things necessary are there in your binary. AFAIK that should work with glibc and assuming you're not doing this on a pocket calculator, the resulting maximum binary size increase of about 2MB wouldn't really hurt you.