<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
