This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: [PATCH]: ld/Makefile.am
On Fri, Mar 10, 2000 at 01:22:19PM -0800, Ian Lance Taylor wrote:
> Date: Fri, 10 Mar 2000 13:19:24 -0800
> From: "H . J . Lu" <hjl@lucon.org>
>
> Please remember that ld/ld-new is called by collect2 which is called
> by the new gcc. When the new gcc runs, it sets up GCC_EXEC_PREFIX,
> INIT_ENVIRONMENT, COMPILER_PATH and LIBRARY_PATH which point to
> itself which is the new gcc. When collect2 calls ld/ld-new, it
> passes all those to ld/ld-new. When ld/ld-new calls "gcc", which
> is the correct compiler to build the whole chain, that gcc driver
> will see GCC_EXEC_PREFIX, INIT_ENVIRONMENT, COMPILER_PATH and
> LIBRARY_PATH set up by the new gcc. Of course, it won't work.
> ld/ld-new tries 4 times to relink the new ld. Every time it will
> append at least COMPILER_PATH and maybe other environment variables.
> It won't help anything.
>
> When ld-new is a shell script, it is doing a special case of
> relinking. The shell script could look down COMPILER_PATH and if it
> is going to reinvoke itself. If so, it could remove the directory
> from COMPILER_PATH.
>
I tried it. It didn't work. I believe GCC_EXEC_PREFIX also plays a
role. I don't know if other gcc environment variables are also
contributing to it.
> Perhaps we could make this a special patch in the ld libtool support.
It is a very special case indeed. I don't know if there is
any clean solution.
H.J.