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
