我在使用 GCC 4.5 的 Mac OS X 10.6.6 下遇到了一些非常奇怪的静态 boost 库问题（来自 MacPorts 的 Boost 1.45.0-2，编译为 fat/universal (x86/x86_64) 库）。
错误信息是
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)
以及一小段会触发此问题的示例代码：
#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';
}
将静态 boost 库链接到二进制文件时总是会出现此问题。不过，动态链接会很好地工作。
更多信息：
测试/使用的 gcc 版本：Apple GCC 4.2.1（工作/运行）、MacPorts GCC 4.5.2（失败）
测试/使用的标志：无、-fPIC、-fPIC -g、-fPIC -g -ggdb3 -gdwarf-2 -O0
带有 MP GCC 4.5.2/上述任何标志的 gdb 输出：
(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
看起来它在 Apple 的（相当旧的）GCC 版本上工作得很好，但在 MacPorts 构建的新 GCC 上却严重失败。
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.
由于 Apple 的 GCC 尚不包含任何 C++0x 功能，因此我确实想使用当前稳定的 GCC 版本。
有谁知道为什么会发生这种情况，甚至可能有解决方案（而不是使用动态库解决方法）？
此致，
Mihai
