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
