This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libstdc++/41645] Massive failures in parallel test mode



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]