Re: [PATCH]: ld/Makefile.am

["H . J . Lu" <hjl at lucon dot org>]

On Sat, Mar 11, 2000 at 07:46:05PM -0300, Alexandre Oliva wrote:
> On Mar 10, 2000, "H . J . Lu" <hjl@lucon.org> wrote:
> 
> > 1. The new gcc calls collect2.
> > 2. collect2 calls ld/ld-new.
> > 3. ld/ld-new uses the new gcc to relink the new ld.
> 
> No.  It's using the old GCC, but it is not using the old linker,
> because the environment variables that the external compiler driver
> sets up: they shouldn't affect the internal compiler that libtool uses
> to re-link the executable, but they do.
> 
> I think the right thing to do is to arrange for the libtool
> wrapper/relinker script to set GCC_EXEC_PREFIX, COMPILER_PATH and
> LIBRARY_PATH to the values they had when the wrapper script was
> created, if the compiler in use is GCC.
> 
> Here's an (untested, because I have to leave right now) patch that
> should fix this problem.  I'll make sure a similar (at least in
> spirit) patch gets into the libtool CVS tree.  The final (i.e., for
> libtool) version should probably only save these variables if GCC is
> the compiler in use, but this is not strictly necessary, and it won't
> hurt to put is in as-is in the Sourceware CVS repo (assuming it
> works :-)  Ok to install?
> 

I have thought about it. I am not very sure if it is a right thing
to do. Are GCC_EXEC_PREFIX, COMPILER_PATH and LIBRARY_PATH valid
environment variables for a user to set? Is that ok for a user to
set them for the old gcc to use? If they are for users to use, a user
may set them up for the old gcc used to compile the new ld and gcc.


H.J.