From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8489 invoked by alias); 18 Dec 2012 17:39:14 -0000 Received: (qmail 8387 invoked by uid 22791); 18 Dec 2012 17:39:12 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_VIA_APNIC,TW_WH X-Spam-Check-By: sourceware.org Received: from comm.purplecow.org (HELO comm.purplecow.org) (210.87.62.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 18 Dec 2012 17:39:03 +0000 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from comm.purplecow.org ([127.0.0.1]) by comm.purplecow.org (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTP id <0MF8006EPMCYKE10@comm.purplecow.org> for gcc-help@gcc.gnu.org; Wed, 19 Dec 2012 04:38:58 +1100 (EST) Received: from comm.purplecow.org ([127.0.0.1] helo=comm.purplecow.org) with IPv4:25 by ASSP.nospam; Wed, 19 Dec 2012 04:38:58 +1100 Received: from [66.103.52.207] by comm.purplecow.org (mshttpd); Tue, 18 Dec 2012 12:38:58 -0500 From: Dennis Clarke To: Ian Lance Taylor Cc: gcc-help@gcc.gnu.org Message-id: Date: Tue, 18 Dec 2012 17:39:00 -0000 Subject: Re: GCC 2.7.2 stage3 bootstrap error on RHEL6 : collect2: error: ld returned 1 exit status In-reply-to: References: X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2012-12/txt/msg00079.txt.bz2 > > collect2: error: ld returned 1 exit status > > gmake[3]: *** [gnat1] Error 1 > > gmake[3]: Leaving directory `/usr/local/build/gcc-4.7.2_2.6.32-279.14.1.el6.x86_64/gcc' > > gmake[2]: *** [all-stage3-gcc] Error 2 > > gmake[2]: Leaving directory `/usr/local/build/gcc-4.7.2_2.6.32-279.14.1.el6.x86_64' > > gmake[1]: *** [stage3-bubble] Error 2 > > gmake[1]: Leaving directory `/usr/local/build/gcc-4.7.2_2.6.32-279.14.1.el6.x86_64' > > gmake: *** [all] Error 2 > > real 8382.63 > > user 7431.50 > > sys 734.14 > > > > > > I would expect to see a failure in stage 1 or stage 2 but rarely > ever stage 3. If anyone > > has a clue where to look for such a beastly error, do let me know. Please. > > This looks like the linker failed without reporting an error message. > That is quite strange. I agree, which is why I thought to post a message to gcc-help in the hopes that someone else could confirm my thinking, this shouldn't happen. Not in stage3. > I do not know what would caused that, and it > suggests a bug in the linker. I was also curious why /usr/local/bin/gld was not used as opposed to the Red Hat supplied ld. I suspect this is due to the specs in the supplied gcc that comes with RHEL6, however I had thought that by stage 3 I would be running the most recent gcc created in stage 2 and with the linker and assembler specified on the conffigure line. In this case gas and gld in /usr/local/bin from binutils 2.23.1. So yes ... this is an odd one to me on a few levels. > You should make sure that you did not run out of disk space That was my first thought as and ada/gnat enabled compiler can be quite large. Nope. Plenty of space. >... and that the linker did not run over some sort > of resource limit, e.g., set by ulimit. sedna $ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 127435 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 1024 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited I could try to increase stack size and max locked memory perhaps but again, I am just on a fishing expedition here. I will say that I dropped the ada language and then was able to get a somewhat ugly build done : http://gcc.gnu.org/ml/gcc-testresults/2012-12/msg01573.html ..in whcih we see somewhat ugly g++ results : === g++ Summary === # of expected passes 48523 # of unexpected failures 51 # of expected failures 286 # of unresolved testcases 28 # of unsupported tests 578 However it was the best I could get at the time. I will see if an increase in stack size makes any difference, as for max locked memory, I can not recall ever needing to touch that. I will say that my bootstraps of 4.7.2 have not gone well and I can not recall in years having such struggles. My best quality ( measured by testsuite ) bootstrap result to date has been on an obsolete Solaris 8 i386 server. Everything throws a pile unexpected failures. I wwill go back and retry a bootstrap with ada and see what I get. Thank you for the pointers and the reply. Dennis