Just to clarify a few things. First Derek meant newer GCC not FCC (unless he's doing some broadcasting work that I'm not aware of) but you probably figured that out. Secondly, I believe that we also meant "always" grab and use that newer version of GCC from the Mac HPC project because we've had numerous problems with linking fortran libraries with the modified GCC version supplied by Mac. Other factors that _might_ have an impact on this bug include whether or not one uses shared or static libraries. The Mac platform does some interesting things with lookup when using shared libraries which is why we have all the rest of those extra linking flags in there. We typically run with dynamic libraries for multiple reasons so I'll have to go back and recompile with static libraries to see if that has an impact. Please confirm if you are using the stock apple supplied GNU compilers "gcc -v" and let us know. I'm interested in seeing if this is problem is localized to the Mac versions of the compilers or more widespread. I'll let you know if I find anything interesting.
Cody On Tue, Apr 27, 2010 at 5:17 PM, Derek Gaston <[email protected]> wrote: > This is odd... We use macs as our primary development machines and > haven't noticed this. It might be because we typically load newer > versions if FCC from the mac HPC project. Are you just using the one > supplied by Apple? > > You should definitely think about grabbing some of the prebuilt gcc's > from the mac HPC project. For one thing it comes with gfortran... > > Derek > > Sent from my iPhone > > On Apr 27, 2010, at 2:29 PM, David Maxwell <[email protected]> wrote: > > > Hi all: > > > > There appears to be a bug in Apple's gcc shipping with OS X 10.6 > > related to run time type identification, templated derived classes, > > and shared libraries. While this is not a bug in libmesh, it affects > > libmesh. Using libmesh version 3802, examples 9 and 14 (among > > others) compile but throw a run time exception because a dynamic > > cast fails. > > > > I was able to work around this problem by changing the line > > > > libmesh_CXXSHAREDFLAG = -dynamiclib -Wl,-undefined,dynamic_lookup,- > > flat_namespace > > > > in Make.common to > > > > libmesh_CXXSHAREDFLAG = -ldylib1.o -dynamiclib -Wl,- > > undefined,dynamic_lookup,-flat_namespace,-no_compact_linkedit > > > > The dynamic casts are now fine. There are instances of a few other > > projects out there running into this bug: > > > > http://openradar.appspot.com/7512422 > > > http://raichoo.blogspot.com/2009/09/bug-snow-leopards-dynamiccast-und.html > > http://www.mail-archive.com/[email protected]/msg00974.html > > > > It might be worthwhile to update libmesh's configure with a > > workaround. > > > > David Maxwell > > > > > > --- > > --- > > --- > > --------------------------------------------------------------------- > > _______________________________________________ > > Libmesh-users mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/libmesh-users > > > ------------------------------------------------------------------------------ > _______________________________________________ > Libmesh-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/libmesh-users > ------------------------------------------------------------------------------ _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
