On Wed, 26 Sep 2012, Andrew E Slaughter wrote:

Thanks for the help. I am trying to build the latest svn build (r6119) but get 
the following error, has anyone received this before? I was
previously using 0.7.3.1 which compiles and runs fine on my system. I used the 
following command for configuration: ./configure --disable-slepc
--with-vtk-include=$VTK_INCLUDE_DIR.
--- Building Metis ---------------------------
make[2]: Entering directory 
`/home/slaughter/packages/libmesh/contrib/metis/GKlib'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory 
`/home/slaughter/packages/libmesh/contrib/metis/GKlib'
make[2]: Entering directory `/home/slaughter/packages/libmesh/contrib/metis/Lib'
Compiling C (in optimized mode) balance.c...
balance.c: In function ‘libmetis__Bnd2WayBalance’:
balance.c:50:3: error: ‘WCOREPUSH’ undeclared (first use in this function)
balance.c:50:3: note: each undeclared identifier is reported only once for each 
function it appears in

That undeclared symbol should be a macro defined in macros.h, included
into balance.c via metislib.h.  Any of which might have changed in
between libMesh 0.7.3.1 and the current svn; we upgraded our copy of
METIS to the latest available a few months ago.

Is it possible you've got another macros.h file or metislib.h file
installed in a system include directory and your compiler is finding
the undesired one first?  If so then uninstalling the conflicting
package might be a reasonable workaround.  Either that or you could
configure libMesh with METIS and ParMETIS disabled and see if our
space-filling-curve-partitioner-that-nobody-uses capability is still
in working order...

Regardless, we should probably make it harder for such a problem to
come up.  We just added an option to force libMesh headers to be
included as "libmesh/whatever.h" to avoid exactly those sorts of
conflicts, but there's currently nothing preventing header naming
conflicts from affecting some of the third-party packages in our
contrib/ directory.

Copying this to libmesh-devel in case anyone has other ideas; I hate
to have any significant "fork" between our copies of contrib/
libraries and the upstream sources, and changing all their #include
directives might qualify as significant.
---
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

Reply via email to