Mac OS X and static boost libs -> std::string fail

Question

I'm experiencing some very weird problems with static boost libraries (Boost 1.45.0-2 from MacPorts, compiled as fat/universal (x86/x86_64) libraries) under Mac OS X 10.6.6 with GCC 4.5.

The error message is

main(78485) malloc: *** error for object 0x1000e0b20: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
[1]    78485 abort (core dumped)

and a tiny bit of example code which will trigger this problem:

#define BOOST_FILESYSTEM_VERSION 3
#include <boost/filesystem.hpp>
#include <iostream>

int main (int argc, char **argv) {
  std::cout << boost::filesystem::current_path ().string () << '\n';
}

This problem always occurs when linking the static boost libraries into the binary. Linking dynamically will work fine, though.

Even more information:

gcc versions tested/used: Apple GCC 4.2.1 (works/runs), MacPorts GCC 4.5.2 (fails)

flags tested/used: none, -fPIC, -fPIC -g, -fPIC -g -ggdb3 -gdwarf-2 -O0

gdb output with MP GCC 4.5.2/any flags of the above:

(gdb) run
Starting program: /Users/ionic/crashtest/bin/ctest  Reading symbols for shared libraries .++++++++++++++++++++++.................................................................................................................. done
ctest(80366) malloc: *** error for object 0x100fe6b20: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug

Program received signal SIGABRT, Aborted. 0x00007fff81a4e616 in __kill ()
(gdb) bt full
#0  0x00007fff81a4e616 in __kill () No symbol table info available.
#1  0x00007fff81aeecca in abort () No symbol table info available.
#2  0x00007fff81a066f5 in free () No symbol table info available.
#3  0x0000000100f763e9 in std::string::_M_mutate () No symbol table info available.
#4  0x0000000100f7644c in std::string::_M_replace_safe () No symbol table info available.
#5  0x0000000100f77edd in std::string::replace () No symbol table info available.
#6  0x000000010000713d in std::string::_M_rep () at /usr/include/c++/4.2.1/bits/basic_string.h:1412
        to = (string &) Cannot access memory at address 0x0

Seems like it's working fine with Apple's (quite old) GCC version, but failing badly with the new GCC build by MacPorts.

otool -L ctest:

./../../bin/ctest:
        /opt/local/lib/gcc45/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.14.0)
        /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 625.0.0)
        /opt/local/lib/gcc45/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.1)

I've seen various reports for quite a similar OS X bug with GCC 4.2 and the _GLIBCXX_DEBUG macro set, but this one seems even more generic, as I'm neither using XCode, nor setting the macro (even undefining it does not help. I tried it just to make sure it's really not related to this problem.) Doesn't seem to be related at all to this problem, as the same code is working fine with Apple's GCC.

As Apple's GCC doesn't include any C++0x features yet, I'd indeed like to use the currently stable GCC version.

Does anybody have any pointers to why this is happening or even maybe a solution (rather than using the dynamic library workaround)?

Best regards,

Mihai

Answer 1

The problem was that Boost has been built using Apple's GCC 4.2.1, whilst I've been building the project using a different compiler.

As I tried to link the static Boost libraries, also the GCC 4.2.1 libstdc++ was put into the binary. However, at the same time the other GCC version was linking in its libstdc++ and name space problems were inherent, thus the wrong functions were called and the like.

The most simple fix is re-building Boost with your target GCC version and retry the building of your program (ofc. using the self-built Boost.)

Be warned: do not try to change the compiler MacPorts uses for building Boost (it's even not easily possible), or system breakage may occur. Instead, build Boost on your own.