------- 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

Reply via email to