This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/41645] Massive failures in parallel test mode
- From: "chris at bubblescope dot net" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 9 Oct 2009 15:10:47 -0000
- Subject: [Bug libstdc++/41645] Massive failures in parallel test mode
- References: <bug-41645-9525@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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