[Libmesh-users] Fwd: metis and libmesh installed

[John P. <jwp...@gm...>]

---------- Forwarded message ---------
From: John Peterson <jwp...@gm...>
Date: Thu, Sep 20, 2018 at 9:11 AM
Subject: Re: [Libmesh-users] metis and libmesh installed
To: <ca...@gf...>




On Thu, Sep 20, 2018 at 6:09 AM Mauro Cacace <ca...@gf...> wrote:

> Dear all,
>
> I am trying to install libmesh (as a part of the MOOSE framework) on a
> cluster (no root). The problem is that I am continuously having this
> error message:
>
> "/ld: gk_cur_jbufs: TLS definition
> in*/usr/local/lib/libmetis.a(error.c.o)* section .tdata mismatches
> non-TLS definition in /cluster/petsc/petsc-3.9.3/lib///libmetis.so
> <http://libmetis.so>//section .data//
> //*/cluster/petsc/petsc-3.9.3/lib/*/*/libmetis.so
> <http://libmetis.so>/*/: error adding symbols: Bad value//
> //make[1]: *** [meshid-opt] Error 1//
> //make[1]: *** Waiting for unfinished jobs..../"
>
> The problem is that there is a conflict of libraries (metis shared and
> static). The PETSc version installed (against which I would like to
> link) does provide a so library (under cluster/petsc/petsc-3.9.3/lib).
> However, libmesh always tries always to further link to an existing old
> static libraries in the common path (under /usr/local/lib/).
>
> I already asked on the MOOSE user group, and received this answer:
>
> /"//The issue seems to be that there are two libmetis libraries under
> consideration by the linker, and because their thread-local storage
> ("TLS") declarations disagree, the linker throws an error. The only way
> we have been able to fix this in the past is to remove the system
> libmetis (the one in /usr/local/lib) completely, but this is obviously
> not acceptable in all situations, so it would be nice to come up with a
> better solution. It would be nice, for example if the "first"
> //libmetis.so <http://libmetis.so>//could somehow take precedence and
> the second one could be ignored...//"/
>
> The IT administrator asks whether it is possible to exclude the static
> library from the making (I think it would not be possible to delete it).
> However, it is not clear to me if that is possible at all, and where.
>
> Any suggestion/help/way out would be really appreciated.
>

Hi Mauro,

Can you send me the config.log file from your build directory on this
machine (either direct email or Google drive link, this list does not allow
attachments).

Also, would it be possible for me to get temporary access to the cluster on
which you are experiencing the problem? None of our local machines exhibit
the issue, so it's impossible to reproduce/fix locally.

-- 
John


-- 
John