This simple test program segfaults: std::cerr << "test"; if it is built with a gcc that was built with binutils 2.23.[12]. If the gcc is built with binutils 2.22-r1 it works. It is not sufficient if the program is linked with binutils 2.22-r1 and the gcc was built with 2.23.[12]. I have tested with gcc versions 4.5.4 (from stage3 tarball), 4.6.4, 4.7.2, and 4.8.2 (vanilla), all show the same error. After I rebuild 4.8.2 (this time with Gentoo patches) using the downgraded binutils it worked. The behavior was reproduced by another user on an independent machine. Reproducible: Always
i think the "on sparc" part is critical. we would have noticed already if this was a wider problem.
Seems that's why emerging cmake fails (configuration phase : Boostrap.cmk/cmake SIGSEGV in libstdc++.so.6.0.14) (even I used pure stage3-sparc64-20130804 or stage3-sparc64-20131104) I think that's a same issue: http://forums.gentoo.org/viewtopic-p-7411850.html After downgrading binutils to 2.22-r1 and simply re-emerging gcc, things are working fine (thanks Rolf Eike Beer)
That's how I noticed it in the first place. ;)
I'm on gcc 4.7.3 and binutils 2.23.52.0.2.20130423 cat test.c #include <iostream> using namespace::std; int main(){ std::cerr << "test"; return 0; } g++ test.c && ./a.out test cmake also builds here. More details in the cmake bug report. https://bugs.gentoo.org/show_bug.cgi?id=494270
*** Bug 494270 has been marked as a duplicate of this bug. ***
Upgrading to binutils-2.23.2 and reemerging gcc fixes it for me.
Rolf: can you double check ? your report says 2.23.[12] ...
Indeed, rebuilding the compiler (I tested only 4.8.2) with 2.23.2 fixed it. I had the assumption that I already did this.
ok, let's start the stabilization process for 2.23.2
(In reply to SpanKY from comment #9) > ok, let's start the stabilization process for 2.23.2 I'd also suggest to make a new revision for gcc that has this version of binutils as DEPEND, to be sure that all people will recompile gcc after the binutils upgrade.
(In reply to Agostino Sarubbo from comment #10) i don't see why that'd guarantee a recompile. that'd only make sure binutils-2.23.2 was installed before gcc itself is built.
(In reply to SpanKY from comment #11) > (In reply to Agostino Sarubbo from comment #10) > > i don't see why that'd guarantee a recompile. that'd only make sure > binutils-2.23.2 was installed before gcc itself is built. If you make a new revision with the stable keyword(for sparc) it will compile first the new binutils version and then gcc itself.
(In reply to Agostino Sarubbo from comment #12) that is true, but that's not something we generally do as it's kind of ugly to manage. if the # of people impacted here is small, then it's reasonable to just say "rebuild it by hand".
I've been holding the removal of the lto USE flag on GCC for just such an occasion. It will trigger the rebuild you want.
2.23.2 is stable now on sparc
