This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

How is [re]located?

I'm not sure that this is the right place to ask, but I think glibc is responsible for, 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 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/, instead of /lib/

Thanks -


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]