# FreeFem Compilation problem on Fedora / mshmet/parmmg

**URL:** <https://community.freefem.org/t/freefem-compilation-problem-on-fedora-mshmet-parmmg/1543>\
**Category:** FreeFEM installation\
**Created:** [February 21, 2022, 4:40pm UTC](https://community.freefem.org/t/freefem-compilation-problem-on-fedora-mshmet-parmmg/1543 "2022-02-21T16:40:48Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![ffeppon](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.freefem.org/ffeppon/32/1011_2.png) [@ffeppon](https://community.freefem.org/u/ffeppon)\
**Post date:** [February 21, 2022, 4:40pm UTC](https://community.freefem.org/t/freefem-compilation-problem-on-fedora-mshmet-parmmg/1543/1 "2022-02-21T16:40:48Z")

</div>

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:

> <https://gitlab.com/florian.feppon/software-recipes/-/blob/public-master/install_freefem_fedora.sh>

PETSc real and complex compile smoothly.

I am then encountering the following compilation bugs:

- when compiling lMesh:

```nohighlight
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

```nohighlight
/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:

```nohighlight
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

```auto
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

---

<div class="post-metadata">

**Author:** ![frederichecht](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.freefem.org/frederichecht/32/15_2.png) [@frederichecht](https://community.freefem.org/u/frederichecht)\
**Post date:** [February 21, 2022, 4:56pm UTC](https://community.freefem.org/t/freefem-compilation-problem-on-fedora-mshmet-parmmg/1543/2 "2022-02-21T16:56:50Z")

</div>

yes you are right !

But it is not easy to do…

---

<div class="post-metadata">

**Author:** ![prj](https://avatars.discourse-cdn.com/v4/letter/p/ecae2f/32.png) [@prj](https://community.freefem.org/u/prj)\
**Post date:** [February 21, 2022, 5:13pm UTC](https://community.freefem.org/t/freefem-compilation-problem-on-fedora-mshmet-parmmg/1543/3 "2022-02-21T17:13:52Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ffeppon](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.freefem.org/ffeppon/32/1011_2.png) [@ffeppon](https://community.freefem.org/u/ffeppon)\
**Post date:** [February 22, 2022, 9:37am UTC](https://community.freefem.org/t/freefem-compilation-problem-on-fedora-mshmet-parmmg/1543/4 "2022-02-22T09:37:28Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![prj](https://avatars.discourse-cdn.com/v4/letter/p/ecae2f/32.png) [@prj](https://community.freefem.org/u/prj)\
**Post date:** [February 22, 2022, 11:38am UTC](https://community.freefem.org/t/freefem-compilation-problem-on-fedora-mshmet-parmmg/1543/5 "2022-02-22T11:38:39Z")

</div>

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 🙂  
I’ve always advocated this solution (see, e.g., [http://jolivet.perso.enseeiht.fr/FreeFem-tutorial/main.pdf#page=197](http://jolivet.perso.enseeiht.fr/FreeFem-tutorial/main.pdf#page=197)), but this can’t be made the default.

---

<div class="post-metadata">

**Author:** ![ffeppon](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.freefem.org/ffeppon/32/1011_2.png) [@ffeppon](https://community.freefem.org/u/ffeppon)\
**Post date:** [February 22, 2022, 12:49pm UTC](https://community.freefem.org/t/freefem-compilation-problem-on-fedora-mshmet-parmmg/1543/6 "2022-02-22T12:49:14Z")

</div>

I see yes, but why not inserting a reference to your solution nonetheless in the FreeFEM documentation at the right place ([Installation guide](https://doc.freefem.org/introduction/installation.html)) ?

---

<div class="post-metadata">

**Author:** ![prj](https://avatars.discourse-cdn.com/v4/letter/p/ecae2f/32.png) [@prj](https://community.freefem.org/u/prj)\
**Post date:** [February 22, 2022, 1:05pm UTC](https://community.freefem.org/t/freefem-compilation-problem-on-fedora-mshmet-parmmg/1543/7 "2022-02-22T13:05:44Z")

</div>

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.
