When I upgraded to binutils 2.16.91 20060413, I started seeing an error when compiling legacy C++ code with GCC 3.3. The error can be reproduced like this: // a.cc: #include <boost/format.hpp> std::string f1() { return boost::format("x").str(); } // b.cc: #include <boost/format.hpp> std::string f2() { return boost::format("y").str(); } // main.cc: #include <cstdio> #include <string> using namespace std; string f1(); string f2(); int main() { printf("%s %s\n", f1().c_str(), f2().c_str()); return 0; } Then: $ g++-3.3 a.cc b.cc main.cc `.gnu.linkonce.t._ZN5boost2io6detail22parse_printf_directiveIcSt11char_traitsIcESaIcEN9__gnu_cxx17__normal_iteratorIPKcSsEESt5ctypeIcEEEbRT2_RKSD_PNS1_11format_itemIT_T0_T1_EERKT3_jh' referenced in section `.rodata' of /tmp/cchMh54t.o: defined in discarded section `.gnu.linkonce.t._ZN5boost2io6detail22parse_printf_directiveIcSt11char_traitsIcESaIcEN9__gnu_cxx17__normal_iteratorIPKcSsEESt5ctypeIcEEEbRT2_RKSD_PNS1_11format_itemIT_T0_T1_EERKT3_jh' of /tmp/cchMh54t.o collect2: ld returned 1 exit status parse_printf_directive, mentioned in mangled form in the error messsage, is a Boost function that gets called from format(). In older binutils (16.91 20060118) I could work around the bug by specifying the -g flag, which caused the bug to go away. That workaround, however, no longer works in 2.16.91 20060413.
It is a gcc bug. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16276 is one of them.
Even if this is caused by a GCC issue, there are still two things to consider: 1. The problem does not appear with older binutils, so they must be doing something right, even if inadvertently. 2. Even if the GCC bug is fixed, the fix will only appear in the 3.4 branch. Lots of third-party C++ code that we use still requires g++ 3.3 to build, and I'm pretty sure we're not the only ones to use such code. In other words, upgrading binutils renders g++ 3.3 useless. If that is the intention, then g++ 3.3 should be removed from distributions that carry it, otherwise this bug will continue to be reported. Of course, removing g++ 3.3 is a huge problem for those who need it to compile older C++ sources.
We see the same problem with ld 2.17 . The problem is as said , that there is code that is/ needs to be compiled with unfixed gcc compilers and it won't relink on systems with newer binutils (eg rhel5). Also binutils 2.15 was patched to compensate for this gcc behavior, see http://sources.redhat.com/bugzilla/show_bug.cgi?id=233
Hi Bert, If you need to link objects compiled with an old (unfixed) gcc, why not use an old set of binutils as well ? The problem with trying to patch the current binutils is that essentially it would be to support buggy behaviour and this introduces bugs into the current linker. Cheers Nick
(In reply to comment #4) > Hi Bert, > > If you need to link objects compiled with an old (unfixed) gcc, why not use an > old set of binutils as well ? > > The problem with trying to patch the current binutils is that essentially it > would be to support buggy behaviour and this introduces bugs into the current > linker. > > Cheers > Nick > I am on openSuse 11.2 which has a gcc3.3-hammer version I was for a long time with Suse 9.3 (gcc 3.3.5) and the same code does not compile now. Should i build binutils myself and which version? How can i instruct the 'hammer' to use these binutils?
Found this http://gcc.gnu.org/faq.html#gas and i make a symlink to ld and as that i have build in my machine and it shows the same error but collect2: ld returned 1 exit status is no longer there and it compiles
Closing. See comment #1 and #4