Re: [Libmesh-users] new libmesh version petsc 3.3 metis linking error

[Jens L. E. <jle...@gm...>]

On 11/28/2012 05:41 PM, Kirk, Benjamin (JSC-EG311) wrote:
> On Nov 28, 2012, at 10:17 AM, "Kirk, Benjamin (JSC-EG311)" <ben...@na...> wrote:
>
>> On Nov 27, 2012, at 5:51 PM, Jens Lohne Eftang <jle...@gm...> 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.
>
Thanks, this seems to work. No complaints during compilation or linking, 
and make check also is all green.

Unrelated, I noted that make check does not seem to run reduced_basis_ex2.