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.
On Dec 3, 2012, at 2:01 PM, "Kirk, Benjamin (JSC-EG311)" <benjamin.kirk-1@...> 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.
> On Dec 3, 2012, at 1:50 PM, "Roy Stogner" <roystgnr@...> 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).