On Nov 28, 2012, at 10:17 AM, "Kirk, Benjamin (JSC-EG311)" <[email protected]> wrote:
> On Nov 27, 2012, at 5:51 PM, Jens Lohne Eftang <[email protected]> wrote: > >> section .tdata mismatches non-TLS definition > > I recreated your PETSc install using version 3.3-p4 (under Linux/Centos 6.2), > using OpenMPI-1.4 and everything is well. Also good with MPICH2-1.4. This > was all with gcc-4.6 > > What compilers are you using? The error message suggests something related > to thread local storage, so it could also be a difference in the way our MPI > stacks are build. I was hoping to recreate this so I could fix it, but if I can't recreate it maybe you can try my idea: Basically, I was going to let libMesh assume METIS is there but not link to its own internal version. Of course, this will rely on linking to petsc to give the required symbol definition. The easiest way to do this is simply comment out #if LIBMESH_ENABLE_METIS # SUBDIRS += contrib/metis # libmesh_la_LIBADD += contrib/metis/libmetis.la #endif inside Makefile.am. This should leave all the preprocessor macros in place to compile the METIS api stuff, but will not compile or link to its own Metis. you may need to bootstrap and rebuild after making this change - let me know what happens… If this works we'll legitimize it with a --enable-metis --with-metis=from_petsc or something like that. -Ben ------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
