Trouble with gcc -B option

[Feuerbacher, Alan]

Hi,

I'm trying to compile a program (octave) using gcc-4.7.1, which I've compiled on my workstation (owned by my employer) which is a Dell Xeon T7500 with two 6-core processesors. It's running Redhat5 (RHEL5) which has a lot of relatively ancient software, which I'm trying to get around by installing late versions of GNU software. I'm far from an expert on this, so please bear with my newbieness.

So far, using information from the LinuxFromScratch folks, I've installed gcc-4.7.1, binutils-2.21.52, glibc-2.15 and a lot of other programs suggested by the LFS website, except for anything that requires root access, since I'm not root on this machine (it's a shared workstation server). All of the software works fine and has passed most of the included tests. All of the gcc-related software is in one directory and all of the octave-related stuff is in a different one.

The problem I'm having now in installing octave is that when my new gcc is run by octave's install script, gcc runs the old RHEL5 ld program rather than the new ld from binutils-2.21.52, which screws up all manner of things. The old programs are incompatible with the new ones in terms of glibc version, ELF version and so forth.

In trying to get this stuff to work, I've tried various things in the gcc manual that I would think would cause gcc-4.7.1 to use the ld from glibc-2.15, but with no success.

The most potentially successful thing is to use the -B option when compiling, but this does not seem to do what the manual describes. I've played with a test program and tried various compile options to see what happens. Here is what I've tried:

######################################################
# In a fresh tcsh window:

  /bin/sh
  source /home/afbacher/.my_octave_pass_exp1_bash_profile
  source /home/afbacher/.my_octave_pass_exp1_bashrc
  printenv

# This gives:

##########
SHELL=/bin/sh
TERM=xterm
LC_ALL=POSIX
LD_LIBRARY_PATH=/usr/lib:/lib:/usr/local/lib
PAGER=less
PATH=/bin:/usr/bin:/usr/local/bin:/usr/bin/X11:/home/afbacher/LFS71/lfs84/bin:/home/afbacher/LFS71/lfs84/usr/bin:/home/afbacher/LFS71/lfs84/sbin:/home/afbacher/LFS71/lfs84/usr/sbin
PWD=/home/afbacher
TZ=America/New_York
PS1=\u:\w\$ 
LESSCHARSET=latin1
SHLVL=1
HOME=/home/afbacher
LESS=-i -N -w  -z-4 -g -e -M -X -F -R -P%t?f%f \
:stdin .?pb%pb\%:?lbLine %lb:?bbByte %bb:-...
LESSOPEN=|/usr/bin/lesspipe.sh %s 2>&-
PKG_CONFIG_PATH=/home/afbacher/GCC/Octave/install/lib/pkgconfig
SHLIB_PATH=/usr/lib:/lib
_=/usr/bin/printenv
##########

  which gcc
##########
gcc is /usr/bin/gcc
gcc is /home/afbacher/LFS71/lfs84/usr/bin/gcc
##########

  which ld 
##########
ld is /usr/bin/ld
ld is /home/afbacher/LFS71/lfs84/usr/bin/ld
##########

# Now compiling a test program:

  echo 'main(){}' >| dummy.c
  /usr/bin/gcc dummy.c -v -Wl,--verbose >| dummy.log 2>&1

  grep 'GNU ld' dummy.log
##########
GNU ld version 2.17.50.0.6-20.el5_8.3 20061020
##########

# As expected the RHEL5 version of gcc uses the RHEL5 version of ld.


# Repeat the above with gcc-4.7.1:

  echo 'main(){}' >| dummy.c
  /home/afbacher/LFS71/lfs84/usr/bin/gcc dummy.c -v -Wl,--verbose >| dummy.log 2>&1

  grep 'GNU ld' dummy.log
##########
GNU ld version 2.17.50.0.6-20.el5_8.3 20061020
##########

# The new gcc is using the old ld.


# Repeat the above with gcc-4.7.1 with -B:

  echo 'main(){}' >| dummy.c
  /home/afbacher/LFS71/lfs84/usr/bin/gcc dummy.c -B/home/afbacher/LFS71/lfs84/usr/ -v -Wl,--verbose >| dummy.log 2>&1

  grep 'GNU ld' dummy.log
##########
GNU ld version 2.17.50.0.6-20.el5_8.3 20061020
##########

# Still using the old ld.


# Now put the path to my gcc-4.7.1 installation first and don't use -B:

  export PATH=/home/afbacher/LFS71/lfs84/usr/bin:${PATH}

  echo 'main(){}' >| dummy.c
  /home/afbacher/LFS71/lfs84/usr/bin/gcc dummy.c -v -Wl,--verbose >| dummy.log 2>&1

  grep 'GNU ld' dummy.log
##########
GNU ld (GNU Binutils) 2.22.52.20120720
##########

# The correct version of ld is used.
######################################################

Any suggestions will be greatly appreciated.

A couple more things possibly of help:

The reason I'm trying the above stuff is that octave's install scripts use /bin/sh, and if I put the path to my new gcc software as the first entry in PATH, /bin/sh complains that the libc.so.6 library is incompatible with it. But if I put /bin etc. as the first entries, gcc uses the wrong ld. Either way I can't compile octave.

Thanks,
Alan