This is the mail archive of the
mailing list for the GCC project.
Re: PATCH Finding gas
- To: Alexandre Oliva <oliva at dcc dot unicamp dot br>
- Subject: Re: PATCH Finding gas
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Wed, 09 Sep 1998 22:39:23 -0600
- cc: Nathan Sidwell <nathan at acm dot org>, egcs-patches at cygnus dot com, Eric Schweitz <schweitz at nortel dot ca>
- Reply-To: law at cygnus dot com
In message <firstname.lastname@example.org>you write:
> This is not always desirable. Assume I have installed gcc
> --with-gnu-ld on SunOS, and GNU ld lives in /usr/local/bin, and some
> other user runs gcc with /usr/bin before /usr/local/bin in the PATH:
> gcc will find /bin/ld, and linking will not work.
Precisely why the selection of when to look at the user's path is so
important. If I was going to select a location it would be near
the end, possibly just before MD_EXEC_PREFIX, but I do not think that
would solve your problem (but would solve the problem that most of
our users face, which is my primary concern right now).
> There must be a way for gcc to remember which assembler and which
> linker it should use, and try them before searching for alternatives.
> Perhaps we should AC_PATH_PROG AS and LD, so that users could define
> which assembler and which linker to use at configure-time. New
> configure options --with-ld=/pathname/to/ld and
> --with-as=/pathname/to/as could be provided too. The existence of GNU
> as and GNU ld could then be auto-detected.
I wouldn't object to being able to provide initial pathnames to search
to find gas & ld at configure time. I would object to schemes which
try to autodetect the location of gas/gld -- that's more of an
interface change than I'm comfortable with.
ps. I'm all too familiar with these issues since I've had the, err,
pleasure of maintaining a port where the vendor provided assembler is
terribly inadequate as a method for generating .o files from compiler