Re: [PATCH] Hard-link to in-tree tools (take 2)

[Daniel Jacobowitz <drow at false dot org>]

On Thu, May 19, 2005 at 11:23:32AM +0200, Paolo Bonzini wrote:
> > I have a patch under testing.
> 
> This implements DJ's suggestion to hard-link in-tree tools at `make' 
> time, and Daniel Jacobowitz's suggestion to always create the links 
> rather than look for arcane conditions.
> 
> Since we do not know in advance if ln will work (because the source may 
> be in a different volume or directory), we fall back to cp in the Makefile.
> 
> This patch also simplifies the configury for detecting a pre-installed 
> `as' and `ld', by moving it to a new macro gcc_AC_PROG.  It uses the 
> same macro to detect nm (previously, if a pre-installed nm was detected, 
> make relied on its being in the PATH).  I am not touching the objdump 
> detection logic, because it is not using outside the configure script.
> 
> Tested with a combined tree toplevel bootstrap on i686-pc-linux-gnu, C 
> and C++ (Java is broken).  Ok for mainline and (the Makefile.def change) 
> for src?
> 
> Paolo

Part of the diff is missing; at least there's no definition for
gcc_AC_PROG.

My main concern with this approach is non-GNU linkers.  What if we
get a non-GNU linker which doesn't work right when copied to a new
location?  That may be a non-problem, but if it crops up, we're going
to need to back out of this or else create the in-tree "linker" as a
shell script fragment to invoke the correct linker.

Hmm, actually, I may be able to break this using just a GNU linker.  If
I have a relocated --with-sysroot linker and you move the binary, it
won't be able to find its sysroot any more, which will probably break
the build of something like shared libgcc.

-- 
Daniel Jacobowitz
CodeSourcery, LLC