How is ld-linux.so.2 [re]located?

[Tom Brown <sa212+glibc at cyconix dot com>]

I'm not sure that this is the right place to ask, but I think glibc is 
responsible for ld-linux.so.2, so here goes...

I'd like to run two versions of gcc, but not in the normal way of 
setting the prefix or suffix. I'm running a cross-compile toolchain to 
generate Linux kernels, so I already have a PowerPC-specific gcc. 
However, the build process has to run the host (x86) gcc to produce 
various tools required in the build.

The problem is that my x86 build machine runs gcc 3.4, and the (very 
old) version of the kernel sources would prefer gcc 2.96. I don't want 
to install 2.96 "properly", because of the risks involved, and because 
this machine is x86_64 and I need a 32-bit compiler, and because it's 
helpful to have a single build system distribution which just includes 
binaries, and because I want to run the kernel build with absolutely no 
changes to the makefiles, and so on. One option is to do a chroot 
install, but I thought I'd try something simpler first.

So, I tried simply copying the 2.96 binaries into /opt/gcc-2.96, and 
just running a simple script in that directory that sets up PATH and 
LD_LIBRARY_PATH.

This does, I think, very nearly work, apart from one problem. The 
problem is that the 2.96 version of the linker thinks it has to find 
ld-linux.so.2 in /lib, and I can't persuade it to look in 
/opt/gcc-2.96/lib instead, which is where the right version is. The 
'/lib' path seems to be hard-wired into the linker.

I've done some googling, and found others with the same problem, but no 
solution. Does anyone have any idea how I can persuade the 2.96 version 
of the tools to generate an executable that loads 
/opt/gcc-2.96/lib/ld-linux.so.2, instead of /lib/ld-linux.so.2?

Thanks -

Tom