This is the mail archive of the gcc-patches@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: PATCH Finding gas



  In message <org1e2w9i4.fsf@tiete.dcc.unicamp.br>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.


jeff

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
output.



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