------- 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
