IRIX 6 configuration sets MD_EXEC_PREFIX

Mark Mitchell
Wed Sep 16 23:52:00 GMT 1998

>>>>> "Jim" == Jim Wilson <> 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> <More sensible things about finding linkers deleted>
    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:


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


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 Mitchell Consulting

More information about the Gcc mailing list