From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22542 invoked by alias); 1 Apr 2008 11:52:37 -0000 Received: (qmail 22346 invoked by uid 48); 1 Apr 2008 11:51:55 -0000 Date: Tue, 01 Apr 2008 11:52:00 -0000 Message-ID: <20080401115155.22345.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "oblivian at users dot sourceforge dot net" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-04/txt/msg00040.txt.bz2 ------- Comment #13 from oblivian at users dot sourceforge dot net 2008-04-01 11:51 ------- (In reply to comment #12) > I think there are two bugs. One is the infinite loop, and H.J.'s patch is > "masking" it by patching gcc/exec-tool.in (which is why I'd prefer to have the > "masking" in ld/Makefile.am). The other is yours, which does not have anything > to do with the infinite loop AFAICS. > I too have an infinite loop at stage 2 "gcc" which is the linker calling itself recursively, but as you can see from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35451, I've been tracing the route of the problem. I agree that the patch is "masking" the problem, but I still think it's a change to gcc that is causing binutils breakage. This may need to be fixed in binutils, but right now I need to figure out what changed in gcc. I did forget to mention the following last night as well... I ran a bootstrap with H.J's patch and it compiles through, but is pulling host libraries. I also ran a profiledbootstrap with H.J.'s patch and it can't find newer gcov_ symbols since it appears to no longer be linking with the latest 4.3.0 libraries and trying against older 4.1.2 gcc libraries. After some stuff I've done this morning, I think it is most definitely related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532 and the search path cleanup on the 4.3.0 branch. I applied the patch as a test, and now I get a /tools/usr/lib directory in the sys_lib_search_path_dirs of my binutils libtool files BEFORE the standard /lib /usr/lib. I think to fix both problems someone needs to describe the "correct" way of providing the retargeted search paths to the binutils configure scripts for stage 2 and beyond. And sysroot is just broken for this at this point, I went through multiple iterations of sysroot trials with no success. I tried adding BOOT_LDFLAGS=-B/tools/usr/lib -B/tools/lib to and passing BOOT_CFLAGS with the same as well and they don't make it to the binutils program configure scripts. Any insight is appreciated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752