This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: IRIX 6 configuration sets MD_EXEC_PREFIX


I added the MD_EXEC_PREFIX definition because I got tired of responding
to bug reports from people who had a program named `as' or `ld' in their
path which was not an assembler or linker respectively.

The most common way that this can happen is if someone is building a cross
compiler, but that isn't the only way.  If someone happens to create a
shell script and call it `ld', I would hope that the compiler would still
work.  This is true if you are using the SGI compiler, because it knows
where the linker is.  This is true if you are using gcc with GNU as and GNU ld,
because gcc will automatically find GNU as and GNU ld.  This is not true
if you use gcc without GNU as and GNU ld, unless MD_EXEC_PREFIX is defined.

There is an additional problem that if the user happens to be missing
directories from his path, then gcc will not work if we rely on searching
the path.  This is particularly a problem on systems where the linker is
in a funny place like /usr/lib/ccs/bin.  This can also be a problem on
systems where the linker is in a popular directory like /usr/bin if the
user made a mistake with the PATH environment variable.

If the compiler can't find as/ld, or finds the wrong ones, then a naive
user will be stuck.  A naive user would never want the compiler to use a
different as/ld than the default one.  An experienced user who does want
to use a different as/ld than the default one can figure out a way to do it.
Hence it is better if the compiler always knows how to find as/ld so that
gcc always works correctly for naive users.

I think all native toolchains should define MD_EXEC_PREFIX to avoid these
problems if GNU as/GNU ld are not required.

Also, note that deleting MD_EXEC_PREFIX does not entirely solve your problem.
If you have GNU as or GNU ld installed, then gcc will automatically find
and use them, even if a different as/ld is first on your path.   Hence
you are still unable to choose which linker to use simply by adjusting your
path.  If you really want an easy way to choose a linker at runtime, then
we would have to add a feature to support that.

Incidentally, the fact that gcc automatically uses GNU ld if it finds it
is one way to control which linker gets used.  Put a link or shell script
or something in the place where GNU ld would be installed that invokes the
linker in /opt/MIPSpro.

I am not familiar with the /opt/MIPSpro directory.  Is that a standard
place where the linker might be found now?  We could add support for
having two directory names.  If /opt/MIPSpro is the more desirable place,
we could defined MD_EXEC_PREFIX to /opt/MIPSpro(/bin?) and define
MD_EXEC_PREFIX_1 to /usr/bin.

Jim


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]