OK, I've finally had a chance to get back to investigating these weird erros that Ata reported.  Using the link he helpfully found, I was able to construct a very small test case that fails on Mountain Lion (10.8) but works fine on my Snow Leopard box (10.6).  

There really is a demonstrable issue with dynamic_casts of templated classes when using shared libraries in new versions of XCode!   To be clear, I actually believe this problem is related to XCode, not the OS, but we typically run older XCode on the older OSes.

This issue does not effect clang builds, but I can't speak to whether this issue shows up with downloaded versions of GCC or not.  I haven't tried that at all.

I have found an ugly workaround, but our linking flags for Apple are already ugly so maybe it's not a big deal?  It turns out that we can drop the manual linking of that "dylib1.o" file and include the linker flag "-mmacosx-version-min=10.5" instead.  I'm going to do some testing on Snow Leopard, Lion, and Mountain Lion with various versions of XCode to make sure this all works.  Once I'm done with that, we'll patch compiler.m4 in libmesh so our users can move forward.

Paul, Roy, Are you guys interested in this small test case?  I can mail one of you guys a small tarball that demonstrates this problem.


On Mon, Sep 3, 2012 at 8:26 PM, Cody Permann <codypermann@gmail.com> wrote:
Sent from my evil iPhone

On Sep 3, 2012, at 7:45 PM, Ataollah Mesgarnejad <amesga1@tigers.lsu.edu> wrote:

> On Sep 3, 2012, at 7:41 PM, Roy Stogner <roystgnr@ices.utexas.edu> wrote:
>> On Mon, 3 Sep 2012, Ataollah Mesgarnejad wrote:
>>> http://stackoverflow.com/questions/6112362/explicit-instantiation-of-a-templated-class-and-dynamic-cast-in-a-shared-library
>>> way over my head here but I think the second answer is the key.
>> This is interesting.  I think the discussion of the C++ standard is
>> wrong, though.  C++ leaves shared library behavior "undefined" only in
>> the same way it doesn't define behavior on Intel processors or
>> behavior on Windows XP; some things (e.g. what happens when
>> dereferencing NULL or reading past the end of an array) are
>> implementation-dependent, but most of the standard is still supposed
>> to be followed.  That includes dynamic_cast; nothing in 5.2.7 suggests
>> otherwise, and grepping through the other thousand pages of the
>> standards draft didn't come up with anything either.
>> But whatever.  Do either of the compiler/linker flags here help?
>> http://www.personal.psu.edu/stm134/Software.html
> No, -Wl,-no_compact_linkedit is obsolete also -Wl,-E or -Wl,--export-dynamic is not recognized.

Ah yes, this is after all, a new bug :). These flags were for an
earlier compiler.


> Best,
> Ata
>> Alternatively, try commenting out the HAVE_RTTI definition in
>> libmesh_config.h - do things then work?
>> ---
>> Roy
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Libmesh-users mailing list
> Libmesh-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libmesh-users