To understand why your binary requires GLIBC_2.25, read this answer.

To understand how you can build a binary which requires older GLIBC version, start here.

There are much simpler ways to downgrade the glibc as well. For example, yum will calculate all of the needed dependencies for you with a

yum downgrade glibc\* 

command. But beware: downgrading glibc is always a really dangerous trick, and it is so on every system.

Glibc on version 2.4 and 2.9 had already very good compatibility between them, I suggest for you the best option were is your 2.9 left.

As j0h described, I was able to solve my problem. Here is what I have done:

1. I read at Wikipedia about glibc. Glibc (better known as GNU C Library) has a fork for linux which is called libc6. Libc6 is available via apt.
2. Run apt-get update to update the database.
3. Use apt-cache policy libc6 to find out the installed version and the candidate version, whereas the installed version can be also shown with ldd --version.
4. Install the new candidate version with apt-get install libc6
5. Check the new version again by doing step 3 again to see your success.

You can definitely compile a new version of GLIBC and have it stored in a separate directory. The first thing you'll have to do is download the version of glibc that you want from http://ftp.gnu.org/gnu/glibc/.

Run the configure script and set the --prefix= to something like /home/you/mylibs.

After you've managed to install it into that directory, you'll have to set your LD_LIBRARY_PATH to the location of the new glibc.

You'll need to figure out any dependencies you may need to compile. You can create a shell script that sets the LD_* variables and the runs your program (which you'd have to do anyway), and run it repeatedly - download/recompiling missing libs along the way.

You could also use ldd to determine what shared libraries the program needs, then use ldd on each of the libraries to find out if they require glibc.

This can be a very time consuming process and is not for the impatient or faint of heart - traversing/recompiling your way through the possible dependencies required to make your application work may occasionally make you want to pull out your hair.

Update 1:

I downloaded glibc-2.4 and tried to compile it on CentOS 6. To get configure working properly I had to change the ac and ld version checks by changing:

2.1[3-9]*)

to:

2.*)

at lines 4045 and 4106 in the configure file itself. I set my *FLAGS environment variables like so:

LDFLAGS="-Wl,--sort-common -Wl,-zcombreloc -Wl,-znow" 
CFLAGS="-pipe -fomit-frame-pointer -g1 -O3 -frename-registers -fweb -ftracer -fmodulo-sched -fvariable-expansion-in-unroller -fgcse-sm"
CXXFLAGS="${CFLAGS}" 
CFLAGS="${CFLAGS} -freorder-blocks-and-partition" 
export LDFLAGS CFLAGS CXXFLAGS

and then executed ./configure --prefix=/home/tim/masochist. It configured properly... and it began building properly too... but then I started running into errors - mostly the compiler complaining about things being redefined.

At that point I gave up... Because it was becoming too time consuming. ;)

In general, binaries that were compiled for an older glibc version will run fine on a system with a newer glibc, as glibc is backward-compatible and handles automatically changes to its application binary interface (ABI). It achieves this wizardry by using symbol versioning, where basically to each symbol is attached a tag specifying its glibc version.

In case of semantics changes to function calls, glibc will include two versions, one for the old semantics and another for the new semantics, so each function is tagged with its version. The linker will consider both versions as two distinct functions.

This sophisticated mechanism is required since glibc is not one file but consists of many pieces (more than 200 shared libraries).

The backward-compatibility of glibc versions is under constant tracking. You may consult the ABI Laboratory report for API/ABI changes review for glibc. The report is generated by the abi-compliance-checker and abi-tracker tools.

For your question:

So if I'm overwriting with a newer libc.so.6 with additional glibc ABI versions inside it, how does it break older apps or leads system to breakage? Or doesn't it...?

Glibc compatibility is not fool-proof, but I believe that you will have to go way back to products compiled on quite old Linux versions to break it. I would also say that products may break not only because of glibc when run on versions of Linux different than where they were compiled.

So the best answer I can give is :
"It's not supposed to break anything, and there is an excellent chance that it won't".

For more information, see:

• The GNU C Library With Versioned Interface
• ABI compliance checker Notes
• ABI Policy and Guidelines