It's a little frustrating there is not a configure-time way to detect these 
conflicts and avoid them - in the best case it results in a link-time error 
like in this Ubuntu case, more pathologically it is bizarre runtime behavior 
like this cppunit weirdness. 

I think I will add an option to not add those preprocessor macros, at least. 

-Ben



On Dec 3, 2012, at 2:01 PM, "Kirk, Benjamin (JSC-EG311)" 
<benjamin.kir...@nasa.gov> wrote:

> I'm afraid you're probably right - I'm in a conference right now on my Mac 
> and couldn't test the issue (because we now disable those flags on Darwin), 
> so was committing that to test elsewhere. 
> 
> -Ben
> 
> 
> On Dec 3, 2012, at 1:50 PM, "Roy Stogner" <royst...@ices.utexas.edu> wrote:
> 
>> 
>> Will r6484 really work with Trilinos?  I'm not saying it's a dumb
>> idea, but I literally just tried to do the same thing for CppUnit this
>> morning, only to discover why it's doomed to fail in many cases:
>> 
>> If you try to turn on _GLIBCXX_DEBUG for libMesh headers and turn it
>> off for Trilinos (or in my case CppUnit) headers, there's *still* only
>> going to be one expansion of the header-guarded STL files: e.g. if
>> libMesh-headers-which-include-vector are included first, then
>> std::vector is defined to be a debug vector.  Then when
>> Trilinos-headers-which-include-vector are included afterwards, that
>> won't redefine a non-debug vector for that code, it will just hit the
>> header guards, it won't re-include the same header twice, the result
>> is equivalent to what already happens when we compile against Trilinos
>> headers with our DEBUG flags turned on, and it will still give
>> segfaults in Trilinos code when the mismatch is hit.  Include the
>> Trilinos headers before the libMesh headers instead, and you just get
>> the segfaults triggered in libMesh code instead.
>> 
>> The only way around this seems to be total separation: use the pImpl
>> idiom in such a way that no code ever needs to include both Trilinos
>> and libMesh headers and no STL containers ever pass from one to the
>> other.  This is basically impossible with CppUnit (way too many macros
>> would need fragile shims), and nearly impossible with Trilinos (most
>> of our NumericVector APIs use std::vector explicitly and would need
>> ugly shim code to turn a debug-vector into a non-debug-vector via a
>> lower-level intermediary).
>> ---
>> Roy

------------------------------------------------------------------------------
Keep yourself connected to Go Parallel: 
BUILD Helping you discover the best ways to construct your parallel projects.
http://goparallel.sourceforge.net
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel

Reply via email to