glibc goes to great lengths to ensure binary backwards-compatibility. If a binary interface has to change it uses symbol versioning to keep around the old interface - for example if you have a program compiled against glibc2.2 on x86-64 that calls timer_create(), it will call through the function __timer_create_old() that provides the old interface when run on a system with a newer libc.
The reverse scenario that seems to be what you have - where you compile against a newer library version then run it on an older one - is forwards-compatibility which is a different kettle of fish. Even on Windows it's not like you can compile against the latest DirectX and run it on an older Windows?
The reverse scenario that seems to be what you have - where you compile against a newer library version then run it on an older one - is forwards-compatibility which is a different kettle of fish. Even on Windows it's not like you can compile against the latest DirectX and run it on an older Windows?