FreeFem Compilation problem on Fedora / mshmet/parmmg

FreeFEM installation
1

Dear all,

I am currently trying to compile the latest version of FreeFEM (version 4.10, commit 9b88bed4d1079b5af424300e) on my fedora distribution.
I am following this recipe:

PETSc real and complex compile smoothly.

I am then encountering the following compilation bugs:

  • when compiling lMesh:
g++ -shared -fPIC -fcommon -Wall -DNDEBUG -O3 -mmmx -mavx -std=c++14 -DBAMG_LONG_LONG -DNCHECKPTR -fPIC -fcommon -DNDEBUG -O3 -mmmx -mavx -std=c++14 -DBAMG_LONG_LONG -DNCHECKPTR -fPIC -I/u/software/ff-petsc/r/include -I/usr/include 'mshmet.o' -o mshmet.so '-L/scratch/users/software/software-recipes/FreeFem-sources/3rdparty/lib' '-lmshmet' '-L/scratch/users/software/software-recipes/FreeFem-sources/3rdparty/lib' '-lMesh

I have the following error

/usr/bin/ld: /scratch/users/software/software-recipes/FreeFem-sources/3rdparty/lib/libMesh.a(memory.o): in function `M_memLeak':
/scratch/users/software/software-recipes/FreeFem-sources/src/libMesh/memory.c:31: multiple definition of `M_memLeak'; /scratch/users/software/software-recipes/FreeFem-sources/3rdparty/lib/libmshmet.a(memory.o):memory.c:(.text+0x0): first defined here
/usr/bin/ld: /scratch/users/software/software-recipes/FreeFem-sources/3rdparty/lib/libMesh.a(memory.o): in function `M_memDump':
/scratch/users/software/software-recipes/FreeFem-sources/src/libMesh/memory.c:36: multiple definition of `M_memDump'; /scratch/users/software/software-recipes/FreeFem-sources/3rdparty/lib/libmshmet.a(memory.o):memory.c:(.text+0x40): first defined here
/usr/bin/ld: /scratch/users/software/software-recipes/FreeFem-sources/3rdparty/lib/libMesh.a(memory.o): in function `M_memSize':
/scratch/users/software/software-recipes/FreeFem-sources/src/libMesh/memory.c:74: multiple definition of `M_memSize'; /scratch/users/software/software-recipes/FreeFem-sources/3rdparty/lib/libmshmet.a(memory.o):memory.c:(.text+0x200): first defined here
/usr/bin/ld: /scratch/users/software/software-recipes/FreeFem-sources/3rdparty/lib/libMesh.a(memory.o): in function `M_malloc':
/scratch/users/software/software-recipes/FreeFem-sources/src/libMesh/memory.c:81: multiple definition of `M_malloc'; /scratch/users/software/software-recipes/FreeFem-sources/3rdparty/lib/libmshmet.a(memory.o):memory.c:(.text+0x240): first defined here
/usr/bin/ld: /scratch/users/software/software-recipes/FreeFem-sources/3rdparty/lib/libMesh.a(memory.o): in  9b88bed4d1079b5af424300efunction `M_calloc':
/scratch/users/software/software-recipes/FreeFem-sources/src/libMesh/memory.c:123: multiple definition of `M_calloc'; /scratch/users/software/software-recipes/FreeFem-sources/3rdparty/lib/libmshmet.a(memory.o):memory.c:(.text+0x360): first defined here
/usr/bin/ld: /scratch/users/software/software-recipes/FreeFem-sources/3rdparty/lib/libMesh.a(memory.o): in function `M_realloc':
/scratch/users/software/software-recipes/FreeFem-sources/src/libMesh/memory.c:168: multiple definition of `M_realloc'; /scratch/users/software/software-recipes/FreeFem-sources/3rdparty/lib/libmshmet.a(memory.o):memory.c:(.text+0x4c0): first defined here
/usr/bin/ld: /scratch/users/software/software-recipes/FreeFem-sources/3rdparty/lib/libMesh.a(memory.o): in function `M_free':
/scratch/users/software/software-recipes/FreeFem-sources/src/libMesh/memory.c:197: multiple definition of `M_free'; /scratch/users/software/software-recipes/FreeFem-sources/3rdparty/lib/libmshmet.a(memory.o):memory.c:(.text+0x550): first defined here
/usr/bin/ld: /scratch/users/software/software-recipes/FreeFem-sources/3rdparty/lib/libMesh.a(memory.o): in function `primem':
/scratch/users/software/software-recipes/FreeFem-sources/src/libMesh/memory.c:224: multiple definition of `primem'; /scratch/users/software/software-recipes/FreeFem-sources/3rdparty/lib/libmshmet.a(memory.o):memory.c:(.text+0x5d0): first defined here
/usr/bin/ld: /scratch/users/software/software-recipes/FreeFem-sources/3rdparty/lib/libMesh.a(memory.o):/scratch/users/software/software-recipes/FreeFem-sources/src/libMesh/memory.c:22: multiple definition of `MAXMEM'; /scratch/users/software/software-recipes/FreeFem-sources/3rdparty/lib/libmshmet.a(memory.o):(.rodata+0x0): first defined here
collect2: error: ld returned 1 exit status

It seems however that the error disappears after removing -lmshmet.

  • Then I have an issue with parmmg:
make[1]: Entering directory '/scratch/users/software/software-recipes/FreeFem-sources/plugin/mpi'
../seq/ff-c++ -auto -mpi parmmg.cpp
eval ../seq/ff-c++ '-mpi' parmmg.cpp -L/scratch/users/software/software-recipes/FreeFem-sources/3rdparty/lib -lparmmg -I/scratch/users/software/software-recipes/FreeFem-sources/3rdparty/include/ -L/scratch/users/software/software-recipes/FreeFem-sources/3rdparty/lib -lmmg -I/scratch/users/software/software-recipes/FreeFem-sources/3rdparty/include/ -L/u/software/ff-petsc/r/lib -lmpicxx -Wl,-rpath -Wl,/u/software/ff-petsc/r/lib -Wl,--enable-new-dtags -lmpi -std=gnu++17 -I/u/software/ff-petsc/r/include -Wl,-rpath,/u/software/ff-petsc/r/lib -L/u/software/ff-petsc/r/lib -lmetis -I/u/software/ff-petsc/r/include -Wl,-rpath,/u/software/ff-petsc/r/lib -L/u/software/ff-petsc/r/lib -lesmumps -lscotch -lscotcherr -I/u/software/ff-petsc/r/include
/u/software/ff-petsc/r/bin/mpicxx -c -fPIC -std=gnu++17 -fcommon -DNDEBUG -O3 -mmmx -mavx -std=c++14 -DBAMG_LONG_LONG -DNCHECKPTR -fPIC '-I../seq/include' '-I/scratch/users/software/software-recipes/FreeFem-sources/3rdparty/include/' '-I/scratch/users/software/software-recipes/FreeFem-sources/3rdparty/include/' '-I/u/software/ff-petsc/r/include' '-I/u/software/ff-petsc/r/include' '-I/u/software/ff-petsc/r/include' -fcommon -DNDEBUG -O3 -mmmx -mavx -std=c++14 -DBAMG_LONG_LONG -DNCHECKPTR -fPIC -I/u/software/ff-petsc/r/include -I/usr/include 'parmmg.cpp'

results in

parmmg.cpp: In member function ‘virtual AnyType parmmg_Op::operator()(Stack) const’:
parmmg.cpp:313:14: error: ‘PMMG_Set_localParameter’ was not declared in this scope; did you mean ‘PMMG_Set_dparameter’?
  313 |         if ( PMMG_Set_localParameter(mesh,/*sol,*/MMG5_Triangle,localParameter(0,j),localParameter(1,j),localParameter(2,j),localParameter(3,j)) != 1 ) {
      |              ^~~~~~~~~~~~~~~~~~~~~~~
      |              PMMG_Set_dparameter
make[1]: *** [Makefile:659: parmmg.so] Error 1
make[1]: Leaving directory '/scratch/users/software/software-recipes/FreeFem-sources/plugin/mpi'
make: *** [Makefile:663: all-recursive] Error 1

Edit: I found the mistake, I needed to remove parmmg.zip in the pkg directory, which was an old version. Maybe it would be safe to make this update automatically when doing git pull ?

Thanks
Florian

2

yes you are right !

But it is not easy to do…

3

Did you install PETSc yourself? Because parmmg.zip is not fetched anymore if you have a working PETSc installation that uses --download-parmmg, and so you won’t have such issues. External packages are handled much more cleanly in PETSc.

4

Ok this works indeed this way. As for the bug with mshsmet, I think it was due to forgetting to do “make clean” before make after ./configure.
I think FreeFEM doc should encourage its users to compile FreeFEM this way, i.e. with PETSc first with the right options. It makes life much simplers on architecture where the user does not have all the right accesses.

5

I think you are missing the big part of the story that 75% of FreeFEM users are on Windows, and don’t know what make or ./configure mean :slight_smile:
I’ve always advocated this solution (see, e.g., http://jolivet.perso.enseeiht.fr/FreeFem-tutorial/main.pdf#page=197), but this can’t be made the default.

6

I see yes, but why not inserting a reference to your solution nonetheless in the FreeFEM documentation at the right place (Installation guide) ?

7

Feel free to make a pull request, I tend not to contribute to FreeFEM documentation anymore because it has became too big and not very usable, IMHO.
BTW, you say (rightfully so) that one should externalize things as much as possible in PETSc instead of within FreeFEM, but in your installation script, you are still missing packages, such as --download-tetgen or --download-htool (only in --with-scalar-type=complex). While you may not use those packages, having them being installed by PETSc instead of FreeFEM reduces the chance of having failures while compiling FreeFEM.