------- Comment #11 from paolo dot carlini at oracle dot com 2009-10-09 15:31 ------- (In reply to comment #10) > To sum up the current state, as things are getting confusing:
A bit yes ;) > 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 Just out of curiosity, it gets linked magically to the new library without telling it to do so? On Linux, I need to add the new path to LD_LIBRARY_PATH, otherwise, it doesn't happen. Any idea how it can be so smart? > 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. Definitely. > 2) For some reason I cannot figure out, this is somehow 'leaking' into my > build. Yes, this is the most mysterious part. One final remark, then I don't see I can do much about this issue right now, I wonder if you can get a fully working compiler + libraries, if you just pass --enable-fully-dynamic-string at build time. That breaks binary compatibility, note (eg, old binaries cannot work fine linked to the new library), but I vaguely suspect that this way you would get a more consistent whole. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41645
