From: Jens L. E. <jle...@gm...> - 2012-11-27 23:51:19
|
All, After svn up ./bootstrap ./configure --my-options make I get a linking error related to my petsc install: *** Warning: Linking the shared library libmesh.la against the *** static library ./contrib/tecplot/lib/x86_64-unknown-linux-gnu/tecio.a is not portable! /usr/bin/ld: gk_cur_jbufs: TLS definition in /home/eftang/dev_software/petsc-3.3-p3/arch-linux2-c-opt/lib/libmetis.so section .tdata mismatches non-TLS definition in contrib/metis/.libs/libmetis.a(error.o) section .data /home/eftang/dev_software/petsc-3.3-p3/arch-linux2-c-opt/lib/libmetis.so: could not read symbols: Bad value collect2: error: ld returned 1 exit status make[1]: *** [libmesh.la] Error 1 I need the petsc metis because I need the mumps solver package. Is this a versions incompatibility issue or something else? Best, Jens |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-11-28 01:02:53
|
On Nov 27, 2012, at 5:51 PM, Jens Lohne Eftang <jle...@gm...> wrote: > I need the petsc metis because I need the mumps solver package. Is this > a versions incompatibility issue or something else? Could be. I've heard about this but haven't seen it myself. Could you post the exact configure line you gave PETSc? I'll try and recreate the error tomorrow, and if I can recreate it I may be able to fix it… -Ben |
From: Jens L. E. <jle...@gm...> - 2012-11-28 10:46:03
|
On 11/28/2012 02:02 AM, Kirk, Benjamin (JSC-EG311) wrote: > On Nov 27, 2012, at 5:51 PM, Jens Lohne Eftang <jle...@gm...> wrote: > >> I need the petsc metis because I need the mumps solver package. Is this >> a versions incompatibility issue or something else? > Could be. I've heard about this but haven't seen it myself. > > Could you post the exact configure line you gave PETSc? I'll try and recreate the error tomorrow, and if I can recreate it I may be able to fix it… > Here's my petsc config: --download-f-blas-lapack=1 --with-mpi-dir=/home/eftang/dev_software/mpich2-install/ --with-debugging=0 --with-shared-libraries=1 --download-metis=1 --download-parmetis=1 --download-mumps=1 --download-scalapack=1 --download-blacs=1 --download-umfpack=1 Jens |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-11-28 16:17:17
|
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. -Ben |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-11-28 16:42:19
|
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. -Ben |
From: Jens L. E. <jle...@gm...> - 2012-11-28 21:10:36
|
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. |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-11-28 21:19:39
|
On Nov 28, 2012, at 3:10 PM, Jens Lohne Eftang <jle...@gm...> wrote: > Thanks, this seems to work. No complaints during compilation or linking, > and make check also is all green. Glad to hear it! > Unrelated, I noted that make check does not seem to run reduced_basis_ex2. Yeah, this is a nuance. Since reduced_basis_ex2 requires SLEPC and GLPK, it only gets run when both are present. The thinking is it doesn't really pass unless it's run for real. We could instead always run it but have it 'return 77' without SLEPC/GLPK, which will make it show "SKIPPED" instead of not run. -Ben |
From: Kirk, B. (JSC-EG311) <ben...@na...> - 2012-11-30 21:32:57
|
On Nov 28, 2012, at 3:19 PM, "Kirk, Benjamin (JSC-EG311)" <ben...@na...> wrote: > On Nov 28, 2012, at 3:10 PM, Jens Lohne Eftang <jle...@gm...> wrote: > >> Thanks, this seems to work. No complaints during compilation or linking, >> and make check also is all green. > > Glad to hear it! In trunk, this behavior is now controlled with the $ ./configure --with-metis=### flag. The default value, internal, will build and link our contrib/metis. $ ./configure --with-metis=PETSc will assume metis is there, but defer defining any metis symbols, expecting instead they will be defined when linking with PETSc. -Ben |