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
