On Thu, Sep 20, 2012 at 10:02 AM, Roy Stogner <royst...@ices.utexas.edu>wrote:
>
> 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
Cody
> ---
> Roy
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
