------- Comment #11 from oblivian at users dot sourceforge dot net 2008-04-01 10:24 ------- (In reply to comment #10) > Subject: Re: [4.3/4.4 Regression]: Combined gcc + binutils > source tree doesn't bootstrap > # 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.
That doesn't make sense from what I'm seeing, so either I need to reopen the bug that I submitted or we are headed down the wrong path. 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. If the above were true, I would not be able to get to stage 2 since the stage 1 ld would have to use the host ld to link itself and from the logs I have... >From stage 1 gcc configure output: checking what linker to use... newly built ld And gcc stage 1 compiles and links. Beyond this, I will reiterate that I can do a complete bootstrap of the 4.3.0 compiler in phase 1, without this patch, and it completes building all stages and works. The compiler in phase 2 of the build, when linking against libraries not in the root /lib and /usr/lib directories is what is confusing the stage 2 programs and not allowing it to work. It appears after more searching that binutils configure scripts are trying to pull the sys_lib_search_path_spec variable from the stage 1 xgcc for all stage 2 programs, and that stage 1 gcc is building and linking against correct library paths, but not incorporating those paths into it's output for -print-search-dirs. Since it doesn't have these paths correctly sys_lib_search_path_spec is set incorrectly by stage 2 configure in ld and libtool gets generated with incorrect library paths thus infecting itself with the host libraries and causing havoc to ensue with the build. So to summarize what I see: Stage 1 ld is built against /tools/lib libraries Stage 1 gcc is built against /tools/lib libraries, but doesn't output these paths with -print-search-dirs Stage 2 ld is build using mixed paths from stage 1 gcc and the environment and tries to link against /lib libraries which apparently causes it to go nuts since everything it is built with is trying for /tools/lib or the recursive loop is libtool flip flopping between linking to /lib then to /tools/lib without making up it's mind. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
