This is the mail archive of the binutils@sourceware.cygnus.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]