This is the mail archive of the
mailing list for the GCC project.
Re: PATCH Finding gas
- To: law at cygnus dot com
- Subject: Re: PATCH Finding gas
- From: Alexandre Oliva <oliva at dcc dot unicamp dot br>
- Date: 10 Sep 1998 04:26:08 z
- Cc: Nathan Sidwell <nathan at acm dot org>, egcs-patches at cygnus dot com, Eric Schweitz <schweitz at nortel dot ca>
- References: <email@example.com>
Jeffrey A Law <firstname.lastname@example.org> writes:
> In message <email@example.com>you write:
>> 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.
I was not suggesting that we should look for gas or gld, I'm just
suggesting that configure searches for `as' and/or `ld' in the PATH if
AS and/or LD are not defined. But now I see this *can* break existing
behavior (for example, it might break my current installation
scripts). Here's a reworked suggestion:
1) if AS (--with-as=...) and/or LD (--with-ld=...) were specified,
these pathnames should be hard-coded in gcc
2) otherwise, if binutils is being compiled with gcc, the pathnames
where as and ld will be installed should be hard-coded in gcc
3) otherwise, no pathname is hard-coded
In any case, if gcc cannot find the hard-coded pathname, it will
perform a search in the `program:' search dirs, as it currently does.
Universidade Estadual de Campinas, SP, Brasil