Description of problem: Trying to link statically e.g. against boost_regexp yields a bunch of linking errors, if the program is also optimized for space. Version-Release number of selected component (if applicable): gcc-4.1.1-30 binutils-2.17.50.0.3-6 boost-devel-1.33.1-6.1 How reproducible: Compile and link this code sniplet: // save as test.cc #include <boost/regex.hpp> using namespace boost; int main () { regex expr("foo"); return 0; } // snip Steps to Reproduce: g++ -Os -o test test.cc -Wl,-Bstatic -lboost_regex -Wl,-Bdynamic Actual results: `.gnu.linkonce.t._ZN5boost9re_detail18basic_regex_parserIcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE20parse_perl_extensionEv' referenced in section `.gnu.linkonce.r._ZN5boost9re_detail18basic_regex_parserIcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE20parse_perl_extensionEv' of /usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libboost_regex.a(instances.o): defined in discarded section `.gnu.linkonce.t._ZN5boost9re_detail18basic_regex_parserIcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE20parse_perl_extensionEv' of /usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libboost_regex.a(instances.o) `.gnu.linkonce.t._ZN5boost9re_detail18basic_regex_parserIcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE20parse_perl_extensionEv' referenced in section `.gnu.linkonce.r._ZN5boost9re_detail18basic_regex_parserIcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE20parse_perl_extensionEv' of /usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libboost_regex.a(instances.o): defined in discarded section `.gnu.linkonce.t._ZN5boost9re_detail18basic_regex_parserIcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE20parse_perl_extensionEv' of /usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libboost_regex.a(instances.o) `.gnu.linkonce.t._ZN5boost9re_detail18basic_regex_parserIcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE20parse_perl_extensionEv' referenced in section `.gnu.linkonce.r._ZN5boost9re_detail18basic_regex_parserIcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE20parse_perl_extensionEv' of /usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libboost_regex.a(instances.o): defined in discarded section `.gnu.linkonce.t._ZN5boost9re_detail18basic_regex_parserIcNS_12regex_traitsIcNS_16cpp_regex_traitsIcEEEEE20parse_perl_extensionEv' of /usr/lib/gcc/i386-redhat-linux/4.1.1/../../../libboost_regex.a(instances.o) [...removed many similar messages...] collect2: ld returned 1 exit status Error 1 Additional info: This seems to be a regression. There are various bug reports on the net showing that this might be a gcc bug uncovered by newer binutils, however these reports are against gcc 3.X, so I'm not sure if this is relevant here.
Jakub this still happens on FC6 with the latest packages. I rebuilt boost-1.33.1-9 from cvs/boost/devel in dist-fc7, but don't know how to get onto an active rawhide host to test with the rebuilt package, sorry. I am also curious.
Rebuilt package + binutils with the HAVE_COMDAT_GROUPS fix, I mean.
The testcase works with: gcc-4.1.1-44 boost-devel-1.33.1-10.fc7 (rawhidish) while doesn't work with gcc-4.1.1-30 boost-devel-1.33.1-6.1 (FC6ish), so I think this is very likely the configury problem with parsing FC6 binutils ld --version that caused HAVE_COMDAT_GROUP not to be defined in gcc < 4.1.1-33.
gcc-4.1.1-47.fc6 is now in FC6 testing updates, once it is moved over to final and boost in FC6 is rebuilt with it, this bug should be fixed.
Now that gcc has been officially updated in FC6, boost needs rebuilding and this problem should go away.
Jakub, should I just rebuild FC6 boost-1.33.1-10?
Seems to work using these packages: binutils-2.17.50.0.6-2.fc6 gcc-[c++-]4.1.1-51.fc6 boost-devel-1.33.1-11.fc6
Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers