The latest applicable version of glibc may be required to build some of the components to be installed on your system. For example, if you are using "--with-mysqld-ldflags=-all-static" on the MySQL build, the earlier versions of glibc (e.g. 2.2.93) can cause it to segfault when linked to this library. However, the 2.4 and above version of glibc is only meant to run on the 2.6 and higher Linux kernels using the NPTL implementation of pthreads, which is now the default configuration. The stable 2.3 release series continues to be maintained and can be used on the 2.4 kernels found in the earlier versions of Linux (such as RedHat 8).
Consider the implications very carefully before beginning to build glibc. Getting it to build properly is a total pain in the butt, mainly because the library guys didn't bother to talk to the compiler guys so that the changes each other make screw the other guy and vice versa. Also, threads support continues to be a major goat rope. I guess it must be hard because it changes with every release and it never seems to work right.
Versions of glibc known to work with the required build tools are as follows:
glibc threads gcc binutils
2.3.6 glibc-linuxthreads-2.3.6 3.3.6 2.17
Finally, installing the new glibc on a running system is nigh-on impossible. The reason being is that every command and service that is running on the system probably depends on glibc in one way or another and, since it is dynamically linked, as soon as you replace it, they all immediately start using it. And, in classic Unix package manager style, each of the system components is inextricably linked to all of the others so that it is not possible to replace one piece at a time. All must be replaced en-masse.
Essentially, here's what happens with the typical "make install" of the new glibc into the running system. The install starts copying files into the running system until it gets to the point where it whacks the glibc dynamic library. Since the new library has links into symbols that are part of the loader but the loader dynamic library didn't get replaced yet (the same problem happens if the loader and glibc are replaced in the other order so give up on that bright idea), anything that tries to load now fails with an error that looks something like this "relocation error: /lib/i686/libc.so.6: symbol dlstarting_up, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference". Essentially the new glibc symbols do not match with the old loader.
Of course, its the loader you just effectively hosed so everything stops working, including the copy command in the makefile which was about to copy the correct loader into the shared library directory. But, it fails. So does everything else, including init and your system is as good as broken.
Recovery is possible by pulling the drive out of the system and mounting it on some other, working system. Then, the old glibc can be copied back on top of it and the system may come back. This method also gives a clue as to how to install the new glibc with a hope of success. See below for the answer.
Meanwhile, if you still think its a good idea to build the new glibc, begin by downloading the chosen source from http://www.gnu.org/software/libc/ into a source directory (e.g. /rpm/glibc).
Extract the source:
cd /rpm/glibc
tar -xvzf glibc-x.y.z.tar.gz
At the very least, you should get the thread add-on for earlier versions of glibc (i.e. before 2.4). To do this, download glibc-linuxthreads-x.y.z.tar.gz from the same place where you got the source for glibc.
The add-on source needs to be extracted in the top level source directory. Do it like so:
cd /rpm/glibc/glibc-x.y.z
tar -xvzf ../glibc-linuxthreads-x.y.z.tar.gz
cd ..
Create an object directory for building the library in. Once you've done that, configure and build the library:
mkdir glibc-x.y.z-obj
cd glibc-x.y.z-obj
../glibc-x.y.z/configure --prefix=/usr --enable-add-ons
--enable_kernel=2.4.18
make
or, if TLS is a problem, you probably want to only enable the linuxthreads add-on and disable TLS:
../glibc-x.y.z/configure --prefix=/usr --enable-add-ons=linuxthreads
--enable_kernel=2.4.18 --without-tls
Note that the default installation directory for configure is "/usr/local". However, many systems come with glibc installed in "/usr". Hence, if you wish to replace an older glibc, the need to specify "--prefix=/usr". Also, for Linux systems only, the minimum kernel version should be made known to configure. This will cause compatibility code to be included in glibc so that it can run on the kernel in question, plus all of the later kernels that it encounters.
If you have problems with the glibc build, the following might be useful.
Since you are overwriting the current version of the library with this new one, you may want to test it first (hint, hint). To do this, type:
make check
If the check worked OK, it is time to install the completed build onto your system. The best way to do this is with a second system. Remove the disk from the first system, where the newly built glibc resides and mount it on the second system. Find all occurrences of "/usr" in the build tree files and replace them with "/mnt/usr" (or whatever the mount point is). At that point, as super user, you should be able to install onto the mounted system drive and have things work OK when you reinstall it in the original system:
su
make install
One final parting shot. If you get failures during the copying of the locale files, having to do with invalid character sequences, you will have to edit the Makefile in the ../po directory. Add each of the broken locale files to the list under BROKEN_LINGUAS. The example shown are the ones I've found to be broken:
BROKEN_LINGUAS = cs da el es fi fr gl hu it ja ko nb pl pt_BR sv zh_CN zh_TW
Incidentally, its a lot easier to upgrade to a new OS with the version of glibc that you want than to build and install a new one. Things that make you go, "Hmmmmm".