------- Comment #16 from bonzini at gnu dot org 2008-04-01 12:08 -------
> The stage 1 ld works as far as linking the stage 1 gcc which is directly after
> it. It's only when we get to stage 2 that things break.
This is a red herring. stage 1 ld goes through the same relink process, but it
uses the host ld to do that (no problem). stage 2 ld adds a further
indirection through stage 1's gcc/collect-ld, which is a small script to
discern between when to use prev-ld/ld-new and when to use ld/ld-new; the
presence of a shell script as ld/ld-new, and the fact that the script *uses ld
itself*, is what confuses the gcc/collect-ld script.
So H.J.'s patch in some sense is right, because it fixes the "buggy" script.
The reason I'd prefer ld to be patched is that H.J.'s fix is a tad brittle and
susceptible to changes in libtool; avoiding the one-time relinking is simpler.
But OTOH, until the patched ld/Makefile.am goes into a released version there
is no way to bootstrap a gcc+binutils tree. :-( I'll make up my mind soon.
Anyway, any other problem you have regarding search paths, as I said, a second
bug, and one that should not cause any kind of infinite loop. We have to fix
that one too, of course, but let's sort out this one first, please.
--
bonzini at gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2008-04-01 12:08:52
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
