[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap

["bonzini at gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #10 from bonzini at gnu dot org  2008-04-01 07:08 -------
Subject: Re:  [4.3/4.4 Regression]: Combined gcc + binutils
 source tree doesn't bootstrap

hjl dot tools at gmail dot com wrote:
> ------- Comment #5 from hjl dot tools at gmail dot com  2008-03-31 18:16 -------
> (In reply to comment #4)
>> Patch seems fine, but before approving it I would like a description of why
>> "tries to [...] relink itself" (important part is *re*link itself), and that
>> description should also go in exec-tool.in.
>>
> 
> I am not a libtool person. My best understanding is when shared library
> is enabled, libtool will create a shell script, ld-new, and the real
> executable as .libs/ld-new.  But .libs/ld-new isn't suitable to be
> used in place directly. When the ld-new shell script is run the first
> time, it will relink a new real linker, .libs/lt-ld-new, and use
> .libs/lt-ld-new instead of .libs/ld-new. I hope libtool person can
> provide a real explanation in exec-tool.in.

Ah, right, now I remember seeing this behavior too.  If you wish to 
explore Ralf's proposed usage of -no-fast-install, I would prefer that 
but I cannot approve that patch (which would have to go to the binutils 
maintainers).

Otherwise, please add a comment like this:

# When ld-new is first executed from the build tree, libtool
# will relink it as .libs/lt-ld-new, so that it can give it
# an RPATH that refers to the build tree.  While doing this
# we need to use the previous-stage linker, or we have an infinite
# loop.

and commit the patch.

Paolo


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752