This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Hard-link to in-tree tools (take 2)
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?
Part of the diff is missing; at least there's no definition for
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.