On Tue, 28 Sep 2010, Cody Permann wrote: > First we found that some of the flags in the "gcc debug" sections do > not work with the Apple compilers. Specifically -D_GLIBCXX_DEBUG > and -D_GLIBCXX_DEBUG_PEDANTIC. These flags cause memory > corruption/seg fault issues in _some_ of the libMesh examples when > running the debug version of the code. Hum - I think we saw > something like this on the mailing list last week. What's > interesting is that that user was using the HPC compilers which I > haven't seen affected by this issue.
Interesting but not surprising; it's a broken compiler/libstdc++ specific issue. > I'm curious, why are these flags specifically added here? Are the > regular debug flags not enough or do we really need these more > esoteric flags? The regular debug flags aren't enough. In cases where they would be enough, usually METHOD=devel is what you want instead. Using -O0 and the GLIBCXX_DEBUG options makes METHOD=debug hideously slow, and apparently it's not an option with broken gcc forks, but it's absolutely invaluable in general. Those flags turn on STL validity checks (including bounds checking on std::vector!), and they've found countless bugs for us. I caught an application bug thanks to those options just two days ago. But on the other hand, if broken gcc forks are going to be an issue on one of the most popular supported libMesh platforms, then that's an issue we ought to work around. Let's see if we can detect Apple-specific gcc versions in compiler.m4, then disable the GLIBCXX_DEBUG defines when necessary? > The second issue has already been discussed on the mailing list: > http://www.mail-archive.com/[email protected]/msg02436.html > These flags are still necessary to successfully run libMesh examples > that use RTTI (example 13). This does appear to be a bug in Apple's > linker so perhaps we need those extra cases in the configure scripts > anyway, since Apple will most likely eventually fix that bug. Yeah, but it would be good to avoid that bug in the meantime. I don't much mind our having to work around system-level deficiencies, as long as the workarounds don't interfere with other systems. > As it stands now, libMesh HEAD does not run on Mac OS 10.6 without > third party compilers or hackery in the Make files so this should be > solidified before the next point release. Definitely. --- Roy ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
