Re: GCC 2.7.2 stage3 bootstrap error on RHEL6 : collect2: error: ld returned 1 exit status

[Dennis Clarke <dclarke at blastwave dot org>]

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