On Sat, Mar 11, 2000 at 03:33:15PM -0800, H . J . Lu wrote:
> On Sat, Mar 11, 2000 at 07:46:05PM -0300, Alexandre Oliva wrote:
> > On Mar 10, 2000, "H . J . Lu" <[EMAIL PROTECTED]> 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.
I was wrong. Your patch seems ok. I can compile the full compiler
for ia64 now.
Thanks.
H.J.
