------- Comment #10 from chris at bubblescope dot net 2009-10-09 15:10 ------- To sum up the current state, as things are getting confusing:
Compiling 'testsuite/21_strings/basic_string/inserters_extractors/char/1.cc -I testsuite/util -O2' using /newgccsvn/bin/g++ (recent svn compile) or /usr/bin/g++ (Apple's gcc 4.2.1) No flags: Fine -D_GLIBCXX_PARALLEL (or _D_GLIBCXX_DEBUG): Fails -D_GLIBCXX_PARALLEL (or _D_GLIBCXX_DEBUG) -D_GLIBCXX_FULLY_DYNAMIC_STRING : Works I built my compiler with: ../gccsvn/configure --enable-languages=c,c++ --prefix=/newgccsvn make && make install Using otool -l (an Apple system utility), it looks like when I use the system compiler I get linked against /usr/lib/libstdc++.6.dylib, and when I use /newgccsvn/bin/g++ I get linked against /newgccsvn/lib/libstdc++.6.dylib So there seems to be two issues: 1) Someone in Apple has completely broken their standard library by turning on _GLIBCXX_FULLY_DYNAMIC_STRING and worse not putting that in the headers, which is breaking _GLIBCXX_DEBUG builds and I imagine will cause some other nastyness. 2) For some reason I cannot figure out, this is somehow 'leaking' into my build. Apologises for a few wild goose-cases along the way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41645