This is the mail archive of the
mailing list for the glibc project.
How is ld-linux.so.2 [re]located?
- From: Tom Brown <sa212+glibc at cyconix dot com>
- To: libc-help <libc-help at sourceware dot org>
- Date: Tue, 22 Mar 2011 13:51:18 +0000
- Subject: How is ld-linux.so.2 [re]located?
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
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?