PATCH finding gas and ld

Nathan Sidwell nathan@acm.org
Mon Sep 7 11:35:00 GMT 1998


Alexandre Oliva wrote:
> 
> Jeffrey A Law <law@hurl.cygnus.com> writes:
> 
> >   In message < orr9xs25zw.fsf@tiete.dcc.unicamp.br >you write:
> >> > Anybody got any clues about this? Should I hack configure to check for
> >> > $LD and $AS, use them and force their full paths into the binary?
> 
> >> No!  IMO, `make install' should install links to `as' and `real-ld' if
> >> appropriate.  What do you think?
> 
> > I would much prefer us encourage folks to install the various tools
> > with the same --prefix.  If they do that all this stuff will just
> > work.
Encourage yes, force no. Unfortunately for some of us, this is not a
sensible option. Tools should be flexible about their installation. I
really don't want to duplicate gas, and gnu-ld just to have an
installation of egcs alongside g++ (remember, I'm not root). It is
doubly annoying, because even though `which as' tells me it's gnu as,
and I say --with-gas, egcs silently ignores this.

I have followed through on Alexandre's suggestion to add symbolic links
to as and ld, if they are not located in the buuld tree or the --prefix,
--exec-prefix directories. In doing this I discovered that the current
configure.in is broken in its method of determining the assembler
capabilities. Specifically, if as is not in . or ../gas/, and it's a
native build, the as on the current path is checked. However, when gcc
invokes the assembler it uses the program path, which could be (and in
my case is) different to that used in the configure test.

what this patch does is
a) on native builds fallback to locating the assembler using $(AS) (new
behaviour) and then the current path (current behaviour). If this
location is not in the correct --exec-prefix directory, it is cached as
host_as.
b) ditto on ld
c) Makefile install creates a symbolic link from --exec-prefix/... to
host_as and host_ld, if they are set.

I have added an m4 macro, EGCS_PATH_PROG, which does the locating. This
comes from autoconf's PATH_PROG macro, but is slightly different in that
it checks if the environment variable is already an absolute path. The
autoconf sources are under GNU GPL, so I believe this is ok.

nathan
-- 
Dr Nathan Sidwell :: Computer Science Department :: Bristol University
      You can up the bandwidth, but you can't up the speed of light      
nathan@acm.org  http://www.cs.bris.ac.uk/~nathan/  nathan@cs.bris.ac.uk


More information about the Gcc-patches mailing list