Menu
▾
▴
Re: [Libmesh-users] an anomaly in FINS
|
From: Ming Q <mi...@gm...> - 2010-08-26 18:27:54
|
I also saw the same thing when I run the example 19. But this is gone when I move back to use the petsc-3.0.0-p11. This petsc version did not defined the variable PETSC_HAVE_XMMINTRIN_H then I can run the code ... / Ming Q On Aug 10, 2010, at 5:27 PM, Derek Gaston wrote: > Interesting... I'll get Cody to give this a try. We've never run into this though... and have tons of mac users using ExodusII. But of course that doesn't mean much if we just happen to have gotten lucky for all of this time. > > Derek > > On Aug 9, 2010, at 3:01 PM, Roy Stogner wrote: > >> >> On Mon, 9 Aug 2010, rochan wrote: >> >>> I came across something that is inexplicable to me in the FINS code. >> >> Looks like this might be a more general libMesh-on-OSX issue, so I'm >> going to Cc: to the libmesh-users mailing list. >> >>> When >>> trying to add the option to write out in an Exodus Format in the physics.c >>> code, I tried to insert the line #include "exodusII_io.h" below the line >>> #include "vtk_io.h". The compiler complained with the following: >>> >>> In file included from >>> /Users/rochanupadhyay/software_installs/gcc-4.5.0/lib/gcc/x86_64-apple-darwin10.3.0/4.5.0/include/xmmintrin.h:39:0, >>> from >>> /Users/rochanupadhyay/software_installs/petsc-3.1-p3/include/petscsys.h:1702, >>> from >>> /Users/rochanupadhyay/software_installs/petsc-3.1-p3/include/petscoptions.h:6, >>> from physics.C:48: >>> /Users/rochanupadhyay/software_installs/gcc-4.5.0/lib/gcc/x86_64-apple-darwin10.3.0/4.5.0/include/mm_malloc.h: >>> In function 'void* _mm_malloc(size_t, size_t)': >>> /Users/rochanupadhyay/software_installs/gcc-4.5.0/lib/gcc/x86_64-apple-darwin10.3.0/4.5.0/include/mm_malloc.h:39:7: >>> error: '__error' was not declared in this scope >>> make[3]: *** [physics.lo] Error 1 >>> >>> However when I put in the #include "exodusII_io.h" below the #ifdef >>> LIBMESH_HAVE_PETSC ... block it builds fine and I can output ExodusII files >>> and visualize it in Paraview. It is as if the compiler wants the "#ifdef >>> LIBMESH_HAVE_PETSC ..." to appear at a particular line (line 48 in this >>> case). And adding any lines pushes it down and it complains and does not >>> build. I am not sure what effect I am observing here. It is useful to put >>> the exodus_io header declaration with the other guys (vtk, gmv etc.) but >>> don't know why the compiler is behaving in this way. >> >> Our own stuff in exodusII_io.h is pretty well made unique with the >> libMesh namespace and LIBMESH_ prefix, but we also include the >> third-party C header file exodusII.h, which defines a bunch of >> preprocessor tokens with the possibly-non-unique prefix of EX_, and >> which goes so far as to >> #define TRUE -1 >> >> Yes, that's right: (true == TRUE) == false. (shaking head sadly) >> >> My guess is that one of those definitions is conflicting with some >> internal definition in the Darwin headers. I can't replicate the >> problem on Linux; I'm trying to replicate it on an (older) OSX system >> now. >> >> It looks like we're only scarfing two constants from exodusII.h into >> our own headers. We might be able to move them to extern variables, >> then only include exodusII.h into the few library source files that >> need it rather than into every user source file that wants to >> read/write Exodus stuff. That won't fix any symbol conflicts (just >> postpone them until linking) but it would at least fix any macro >> conficts. If I can replicate the problem here I'll try to do that. >> If I can't then hopefully your workaround will be sufficient until I >> can borrow your laptop or something. >> --- >> Roy >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by >> >> Make an app they can't live without >> Enter the BlackBerry Developer Challenge >> http://p.sf.net/sfu/RIM-dev2dev >> _______________________________________________ >> Libmesh-users mailing list >> Lib...@li... >> https://lists.sourceforge.net/lists/listinfo/libmesh-users > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Libmesh-users mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-users |