Am running 4.7.1 testsuite on alphaev68-dec-osf5.1a, and seeing a lot of 237556:./what-1.exe: /sbin/loader: Error: libstdc++.so.6: symbol "__pthread_mutex_init" unresolved 237556:./what-1.exe: /sbin/loader: Fatal Error: Load of "./what-1.exe" failed: Unresolved symbol name FAIL: 27_io/ios_base/failure/what-1.cc execution test about __pthread_mutex_init being unresolved. The previous testsuite result I summitted (http://gcc.gnu.org/ml/gcc-testresults/2011-08/msg00587.html) also seems to have a lot of unexpected failures for 4.6.1: === libstdc++ Summary === # of expected passes 4091 # of unexpected failures 2312 # of expected failures 80 # of unsupported tests 747 === g++ tests === I'll write again when 4.7.1. finishes.
4.7.1 also have a high failure rate: === libstdc++ Summary === # of expected passes 4583 # of unexpected failures 2519 # of expected failures 41 # of unsupported tests 670 I have a few others and they are similar - about 1/2 failed in libstdc++ .
See my testsuite results for various versions submitted on 25 sept 2012: http://gcc.gnu.org/ml/gcc-testresults/2012-09/ The issue seems to happen with 4.5.0.
Jon, can you have a look to this one? Thanks in advance..
How is GCC configured?
(In reply to comment #4) > How is GCC configured? Just "/where/source/is/configure" with no options. You can see it at the bottom of : http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg02452.html for 4.5.0 http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg02457.html for 4.5.1 all built with 4.3.3. (sorry the one for 4.5.0 has an extra --enable-obsolete - I must have copied it blindly because 4.7.x for Tru64 needed it. But you can see the others on sept 25 http://gcc.gnu.org/ml/gcc-testresults/2012-09/ - there are 20+ of them for various versions, and the 4.5.x and 4.6.x should be without that).
The latest with 4.6.4 and 4.7.3 : http://gcc.gnu.org/ml/gcc-testresults/2014-01/msg00048.html http://gcc.gnu.org/ml/gcc-testresults/2014-01/msg00049.html seems to be a lot healthier. During the course of the latest round, I realised that it seems that GNU strip from GNU binutils seems to confuse the configure system (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959 bootstrap failed at Comparing stages 2 and 3) on -gtoggle ; so I am putting /usr/local/bin *last*, instead of first as previously. gcc these days requires GNU tar to extract, and GNU make, GNU bash to configure and make, so it is almost a habit to put /usr/local/bin first, but GNU strip certainly seems to behave differently from DEC strip. Would any of GNU binutils causes "/sbin/loader: Error: libstdc++.so.6: symbol "__pthread_mutex_init" unresolved"? If there is a simple test, I can try.
4.7 branch closed.