Downgrade_Glibc

If you really want to attempt this, I recommend you have a copy of busybox built with USE="static" around.

Method A

• Get the required version of sys-libs/glibc from Gentoo Binary Packages TinderBox
• Put it in /usr/local/glibc/
• Add your new

LDPATH="/usr/local/glibc/lib:/usr/local/glibc/lib64:/usr/local/glibc/usr/lib64:/usr/local/glibc/lib32:/usr/local/glibc/usr/lib32:$LDPATH"

to /etc/env.d/00basic

• And update environment: env-update && source /etc/profile
• Mask all versions newer than the required version in /etc/portage/package.mask
• Re-emerge your universe: emerge --emptytree system; emerge --emptytree system; emerge --emptytree world

(This method does not work. As soon as ld.so.cache is rebuilt by env-update, none of your dynamic binaries will work any more, including gcc et al.)

Method B

This method has not yet been fully tested.

• Get the target version of sys-libs/glibc from Gentoo Binary Packages TinderBox
• Put it in /usr/local/glibc/
• Add the following to your /etc/make.conf file

 LDFLAGS="-L/usr/local/glibc/lib64 -L/usr/local/glibc/usr/lib64 -L/usr/local/glibc/lib32 -L/usr/local/glibc/usr/lib32 $LDFLAGS"
 CPPFLAGS="-I/usr/local/glibc/usr/include $CPPFLAGS"

• Mask all versions newer than the required version in /etc/portage/package.mask
• Run emerge -pv sys-libs/glibc and verify the correct version would be built.
• Re-emerge your system: emerge --emptytree system
• Remove or rename your /usr/local/glibc directory (the previous rebuild of the system should have built the correct glibc now) and remove the LDFLAGS and CPPFLAGS entries previously added to your /etc/make.conf.
• Re-emerge your universe: emerge --emptytree system; emerge --emptytree world

(This method works good. It doesn't require rebuilding ld.so.cache up-front and so doesn't break your build environment. Although you probably want to run 'env-update && source /etc/profile' after the 'remove /usr/local/glibc' step towards the end)

Method C

This method worked for me, going back from glibc-2.7/8-something to 2.6.1.

• Get the target version of sys-libs/glibc from Gentoo Binary Packages TinderBox
• boot Gentoo mini bootcd, make a /mnt2 directory and mount your system partition there
• chroot there in the first console
• unpack the glibc tbz2 binary package in your system / (which is now /mnt2) (yes, be brave)
• I also did the /usr/local/glibc thing from method A, but I am not sure if this is necessary
• now a simple emerge -C glibc will fail at the end, because an important symlink in /lib64 from ld-linux-x86-64.so.2 to ld-2.8.so will be removed in the process and everything will segfault
• To avoid this, you need to be fast to replace it with a link to the previously unpacked ld-2.6.1 so that the emerge -C glibc will finish somehow
• Compile a static binary (gcc -o nomercy nomercy.c -static) beforehand, which you run in /mnt2/lib64 to do the job mercilessly (note that you must not chroot there, because the ln would not work either when emerge -C glibc has removed the important link!)

#include <stdlib.h> int main (void){ for(;;){ system("ln -s ld-2.6.1.so ld-linux-x86-64.so.2"); } }

• Let this run on a second console (not chrooted!) while you do the emerge -C glibc and it will finish removing that darn package
• Once finished, you can unpack the glibc binary package in your system root again for good measure, reboot as normal and re-emerge glibc some time (and the rest of your world as in the above methods (which both don't really work somehow))
• I did not have to re-emerge the universe, since I had only used ~amd64 on glibc for gcc-4.3 and wanted to go back immediately after realizing the one-way nature of this.

(This method is just crazy and scary. Replacing a link on the fly at just the right time? Are you serious? Use Method B and save yourself lots of frustration and hair pulling.)