Cody and I prepared a patch for compiler.m4 file which should address the build issues with native Apple compilers. It should not interfere with other build systems (see the attachment).
-- David Andrs Roy Stogner <[email protected]> wrote on 09/28/2010 03:58:17 PM: > > 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]. > net/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
compiler-m4.patch
Description: Binary data
------------------------------------------------------------------------------ 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
