native compiler linked to another glibc

[Bill Cunningham via Gcc-help <gcc-help@xxxxxxxxxxx>]

I have a different binutils and gcc that works fine and is connected to 
the system libc. Whew, that's the important thing.

    I compile a newer glibc and save it in a a path in /mnt. The 
problems I seem to be running into I believe are addressed in that FAQs, 
at least in a similar form. I compile, or try to, a native compiler that 
will be attached to the new glibc (not the system glibc).

/source/gcc/configure --prefix=/mnt --disable-bootsrap 
--disable-multilib --disable-nls --enable-languages=c,c++ \

--with-build-time-tools=/mnt/bin CC=/mnt/old-gcc/bin/gcc 
CXX=/mnt/old-gcc/bin/g++

The binutils are in the /mnt/bin. I set '--with-build-time-tools' for 
the binutils. Compilation goes for some time and the compilation wants 
the newer includes from the new glibc. Now the path the compiler seems 
to want to look at is '/usr'bin'. For the linker. '/usr/bin/ld'. I don't 
want it to look there. And there is a complaint that /mnt/lib does not 
contain libc.a not lib_nonshared.a and another statically created 
library. I have not used the '--disable-shared' switch nor it opposite. 
Those libraries are also there. IDK why the compiler can't find 
libraries that are there unless there are links that are not set right. 
And why is it running the system ld and not the test compiler's 'ld'. Hum.

Also' /lib/cpp isn't found', it is in /bin/cpp. It needs to also be in 
/lib, so I will set a link next time. But why is the system linker in 
'/usr/bin/ld' being used and not '/mnt/bin/ld'?

B