Re: IRIX 6 configuration sets MD_EXEC_PREFIX

[Jim Wilson <wilson at cygnus dot com>]

	I think this is only true if you put GNU as/ld in the same directory
	as the compiler (i.e., build with the same --prefix).  Otherwise, I
	think the driver just searches the path.

Yes, you need to use the same prefix.

Gcc will search $tooldir/bin before it searches the path.  GNU as and GNU ld
install themselves in $tooldir/bin.  Generally this is $prefix/$target/bin.
Hence gcc always finds GNU as/ld if they were installed with the same prefix.

	I suggest, then, that native toolchains should determine at
	configure-time where to find the linker/assembler and remember this
	information. 

I don't object to a similar scheme that works at configure time instead of
compile time.  However, how are you going to do the configure time check?
Are you proposing testing to see if the first ld on the user's path works?

I suppose that could work if ld already exists.  This does not work if I
am using a one-tree approach to build ld and gcc at the same time, since
ld won't exist at the time that I configure gcc.  We do this all of the
time at Cygnus, so it would be inconvenient if this broke.  We could perhaps
add special checks to see if there are ../ld and ../gas directories,
and assume that we will find ld and as respectively in tooldir/bin if
these directories exist in the build tree.

We still need a hardwired target dependent directory to check if we can't
find as/ld on the user's path.  We still can't assume that /usr/lib/cmplrs/cc
for instance is on the user's path on an irix5 system.  So we still need
MD_EXEC_PREFIX or something very much like it.

This scheme won't work for cross compilers, because you won't be able to
check whether the linker works at configure time.

This scheme can potentially fail even for native compilers, if they have
more than one linker.  For instance, on an irix6 system, there are actually
two different linkers, the o32 linker, and the n32/n64 linker.  If I put
the o32 linker first on my path, and then do
	setenv CC "cc -32"
then it may appear that the linker on my path works, but it won't be usable
to gcc, and the gcc build will fail.

Also, there are other programs that gcc needs, such as nm and strip.  If
we change how gcc calls as/ld, then we should do the same for all other
programs that gcc may invoke.

This seems like an awful lot of trouble to me.  Adding a MD_EXEC_PREFIX_1
macro would be easier.

We have an Irix 6.5 system here at Cygnus.  I just checked it, and I see
that it has a /opt/MIPSpro/bin directory with a ld in it.  It just points
back to /usr/bin/ld though.  It looks like /opt/MIPSpro/bin is some new
feature of Irix6 that gcc should be supporting.

Jim