This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: IRIX 6 configuration sets MD_EXEC_PREFIX
- To: wilson at cygnus dot com
- Subject: Re: IRIX 6 configuration sets MD_EXEC_PREFIX
- From: Mark Mitchell <mark at markmitchell dot com>
- Date: Wed, 16 Sep 1998 13:41:58 -0700
- CC: egcs at cygnus dot com, wilson at cygnus dot com
- References: <199809162012.NAA24769@rtl.cygnus.com>
- Reply-to: mark at markmitchell dot com
>>>>> "Jim" == Jim Wilson <wilson@cygnus.com> writes:
Jim> I added the MD_EXEC_PREFIX definition because I got tired of
Jim> responding to bug reports from people who had a program named
Jim> `as' or `ld' in their path which was not an assembler or
Jim> linker respectively.
Jim>
Jim> <More sensible things about finding linkers deleted>
Jim>
Jim> I think all native toolchains should define MD_EXEC_PREFIX to
Jim> avoid these problems if GNU as/GNU ld are not required.
I thought you might say that. That's a reasonable point of view, but
one that should probably be debated and decided, and then instituted
across the board, if so. One of my points (badly articulated,
perhaps) was that it seems odd to have GCC behave differently on MIPS
than on other targets.
Jim> Also, note that deleting MD_EXEC_PREFIX does not entirely
Jim> solve your problem. If you have GNU as or GNU ld installed,
Jim> then gcc will automatically find and use them, even if a
Jim> different as/ld is first on your path. Hence you are still
Jim> unable to choose which linker to use simply by adjusting your
Jim> path. If you really want an easy way to choose a linker at
Jim> runtime, then we would have to add a feature to support that.
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.
Jim> I am not familiar with the /opt/MIPSpro directory. Is that a
Jim> standard place where the linker might be found now? We could
Jim> add support for having two directory names. If /opt/MIPSpro
Jim> is the more desirable place, we could defined MD_EXEC_PREFIX
Jim> to /opt/MIPSpro(/bin?) and define MD_EXEC_PREFIX_1 to
Jim> /usr/bin.
On the particular system that I am using, the first ld in my path
(which is how was set up by the sysadmin) is in:
/opt/MIPSpro/MIPSpro_default/opt/MIPSpro/bin/ld
I don't really expect that such a path is terribly standard, and I
didn't install the compilers, so I can't really say. There is also
an:
/opt/MIPSpro/bin/ld
This is a shell script (provided, judging by its copyright
information) by SGI/MIPS, which invokes the real linker. It invokes
the ld that I have in my path. So, I think that, at the least, we
should do what you suggest: set MD_EXEC_PREFIX to /opt/MIPSpro/bin/ld
and fall back on /usr/bin/ld after that. But, I assume that some
people might install the compilers elsewhere, so I'm not too happy
with this solution either.
However (I realize there has been some debate on this issue lately), I
think that the right thing to do is determine at configure-time what
linker/assembler are being used. You are correct to suggest that the
compiler should work, regardless of what's in the user's path, but
just sticking the user with some hard-wired MD_EXEC_PREFIX isn't too
helpful either.
I suggest, then, that native toolchains should determine at
configure-time where to find the linker/assembler and remember this
information. This would allow us to remove MD_EXEC_PREFIX from the
IRIX configuration files (and any others that define thisi for similar
reasons), and provide a uniform way of handling the situation. Note
that we can still provide sensible configure-time defaults (i.e., if
no `ld' is found at configure-time use `/usr/bin/ld').
--
Mark Mitchell mark@markmitchell.com
Mark Mitchell Consulting http://www.markmitchell.com