On Thu, Sep 20, 2012 at 10:02 AM, Roy Stogner <email@example.com>
Not sure if this an option you want, but it's probably worth
mentioning: should we have configure test for when templated casts are
broken across dynamic library boundaries, and then turn off
LIBMESH_HAVE_RTTI whenever that's the case?
Well from a library perspective, this might be the right thing to do, but it makes me wonder what the future of this particular compiler will be on OS X. It feels like Apple is going to eventually stop supporting it and move to Clang/LLVM exclusively. If that's the case, perhaps we could just add the -mmacosx-version-min=10.5 flag to the existing compiler which seems to rectify the problem on newer versions of XCode. I could figure out which versions and adjust compiler.m4 appropriately. No need to adjust libMesh to handle yet another broken compiler.
Internal to the library
we're fine falling back on the static_cast code paths, so this would
at least be a big help to new users on new OS X versions.
What do you guys need Fortran support for? PETSc third-party
libraries? In-house code?
We need Fortran to support various legacy subroutines. We allow our users to re-use existing Fortran for things like material property calculations in MOOSE. It helps ease the transition to C++ that many of our engineering friends have to go through in using the framework. MOOSE itself doesn't have any Fortran in it, but our end applications... That's another story