Add -fPIC flag to linker
Dear kwant user, I am trying to build kwant and its dependencies from sources. A first build without Mumps succeeded. When adding Mumps however, the linker returns the following error: /usr/bin/ld: /opt/mumps-5.4.1/lib/libzmumps.a(ztools.o): relocation R_X86_64_PC32 against symbol `.gomp_critical_user_critical_old_ooc' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: bad value Here is the content of the build.conf [mumps] include_dirs = /opt/mumps-5.4.1/include /opt/scotch-7.0/include library_dirs = /opt/mumps-5.4.1/lib /opt/mumps-5.4.1/libseq /opt/scotch-7.0/lib libraries = zmumps mumps_common pord esmumps scotch scotcherr mpiseq gfortran Would adding -fPIC flag as suggested by the error message solve the issue ? If so, how can this flag be added with the python build setup ? Best, Etienne F
Etienne Fayen wrote :
I am trying to build kwant and its dependencies from sources. A first build without Mumps succeeded. When adding Mumps however, the linker returns the following error:
/usr/bin/ld: /opt/mumps-5.4.1/lib/libzmumps.a(ztools.o): relocation R_X86_64_PC32 against symbol `.gomp_critical_user_critical_old_ooc' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: bad value
I suppose that this is on some kind of Linux? Since mumps and friends are located in /opt I guess they were compiled manually? In which way?
Would adding -fPIC flag as suggested by the error message solve the issue ? If so, how can this flag be added with the python build setup ?
Please check the whole log of compilation (you can also post it here). For example, run python3 setup.py clean -a followed by python3 setup.py build_ext -i During the build process the commands that are executed are echoed. So when you see an error, the command that caused it is immediately above.
Would adding -fPIC flag as suggested by the error message solve the issue ? If so, how can this flag be added with the python build setup ?
On my machine the -fPIC flag is present in all invocations of gcc by setup.py. That should be also the case for you (please check). My first guess is that the problem you experience might be due to mumps/scotch (and not Kwant) being compiled without -fPIC. Hope this helps a bit Christoph
Hi Christoph, thanks for your help. Sorry for the missing information. I am indeed installing on a Linux (Ubuntu 20.04). Mumps and scotch were compiled manually in /opt, following instructions in the readmes. As you correctly pointed out, Mumps was compiled without -fPIC. This was fixed by adding the flag to both OPTF and OPTC in Makefile.inc, and recompiling. Then, recompiling kwant was smooth. The install target for kwant in a virtualenv also located in /opt/python3-venv. After installation though, when importing kwant, I still have the message: /opt/python3-venv/lib/python3.8/site-packages/kwant-1.4.2-py3.8-linux-x86_64.egg/kwant/solvers/default.py:16: RuntimeWarning: MUMPS is not available, SciPy built-in solver will be used as a fallback. Performance can be very poor in this case. It is caused by the following import error: /opt/python3-venv/lib/python3.8/site-packages/kwant-1.4.2-py3.8-linux-x86_64.egg/kwant/linalg/_mumps.cpython-38-x86_64-linux-gnu.so: undefined symbol: GOMP_loop_nonmonotonic_dynamic_start This points again to my hand-built Mumps, so again not a kwant issue per se. Etienne On 17/01/2022 16:00, Christoph Groth wrote:
Etienne Fayen wrote :
I am trying to build kwant and its dependencies from sources. A first build without Mumps succeeded. When adding Mumps however, the linker returns the following error:
/usr/bin/ld: /opt/mumps-5.4.1/lib/libzmumps.a(ztools.o): relocation R_X86_64_PC32 against symbol `.gomp_critical_user_critical_old_ooc' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: bad value I suppose that this is on some kind of Linux? Since mumps and friends are located in /opt I guess they were compiled manually? In which way?
Would adding -fPIC flag as suggested by the error message solve the issue ? If so, how can this flag be added with the python build setup ? Please check the whole log of compilation (you can also post it here). For example, run
python3 setup.py clean -a
followed by
python3 setup.py build_ext -i
During the build process the commands that are executed are echoed. So when you see an error, the command that caused it is immediately above.
Would adding -fPIC flag as suggested by the error message solve the issue ? If so, how can this flag be added with the python build setup ? On my machine the -fPIC flag is present in all invocations of gcc by setup.py. That should be also the case for you (please check).
My first guess is that the problem you experience might be due to mumps/scotch (and not Kwant) being compiled without -fPIC.
Hope this helps a bit Christoph
Etienne Fayen a écrit :
Mumps and scotch were compiled manually in /opt, following instructions in the readmes.
I’m curious, why are you building mumps yourself?
It is caused by the following import error:
/opt/python3-venv/lib/python3.8/site-packages/kwant-1.4.2-py3.8-linux-x86_64.egg/kwant/linalg/_mumps.cpython-38-x86_64-linux-gnu.so: undefined symbol: GOMP_loop_nonmonotonic_dynamic_start
This points again to my hand-built Mumps, so again not a kwant issue per se.
GOMP refers to GNU OpenMP. OpenMP is used for example by OpenBLAS that you are most likely using through Mumps. Perhaps you have to link your Mumps (or some other component) with OpenMP by using the linker flag '-lgomp' or '-fopenmp'. You can also try adding 'gomp' to Kwant’s build.conf under 'libraries'. Christoph
All these complications are due to a --questionnable-- design choice of our cluster. Nodes are diskless: they receive their root filesystem as a squashfs that they store in memory. To keep it squashfs small, scientific programs used in the cluster are installed manually in /opt, which is NFS shared. Adding gomp under 'libraries' worked. I also had to add metis which I forgot earlier. I'm now missing symbol zscal_ from libzmumps. The rabbit whole looks bottomless... Etienne On 17/01/2022 21:54, Christoph Groth wrote:
Etienne Fayen a écrit :
Mumps and scotch were compiled manually in /opt, following instructions in the readmes. I’m curious, why are you building mumps yourself?
It is caused by the following import error:
/opt/python3-venv/lib/python3.8/site-packages/kwant-1.4.2-py3.8-linux-x86_64.egg/kwant/linalg/_mumps.cpython-38-x86_64-linux-gnu.so: undefined symbol: GOMP_loop_nonmonotonic_dynamic_start
This points again to my hand-built Mumps, so again not a kwant issue per se. GOMP refers to GNU OpenMP. OpenMP is used for example by OpenBLAS that you are most likely using through Mumps. Perhaps you have to link your Mumps (or some other component) with OpenMP by using the linker flag '-lgomp' or '-fopenmp'. You can also try adding 'gomp' to Kwant’s build.conf under 'libraries'.
Christoph
Sorry for the double message, I simply forgot to include openBLAS in the libraries for kwant. It now works, and there is no more runtime error when Kwan is imported. Thanks a lot for you help, Etienne On 18/01/2022 11:40, Etienne Fayen wrote:
All these complications are due to a --questionnable-- design choice of our cluster. Nodes are diskless: they receive their root filesystem as a squashfs that they store in memory. To keep it squashfs small, scientific programs used in the cluster are installed manually in /opt, which is NFS shared.
Adding gomp under 'libraries' worked. I also had to add metis which I forgot earlier. I'm now missing symbol zscal_ from libzmumps. The rabbit whole looks bottomless...
Etienne
On 17/01/2022 21:54, Christoph Groth wrote:
Etienne Fayen a écrit :
Mumps and scotch were compiled manually in /opt, following instructions in the readmes. I’m curious, why are you building mumps yourself?
It is caused by the following import error:
/opt/python3-venv/lib/python3.8/site-packages/kwant-1.4.2-py3.8-linux-x86_64.egg/kwant/linalg/_mumps.cpython-38-x86_64-linux-gnu.so:
undefined symbol: GOMP_loop_nonmonotonic_dynamic_start
This points again to my hand-built Mumps, so again not a kwant issue per se. GOMP refers to GNU OpenMP. OpenMP is used for example by OpenBLAS that you are most likely using through Mumps. Perhaps you have to link your Mumps (or some other component) with OpenMP by using the linker flag '-lgomp' or '-fopenmp'. You can also try adding 'gomp' to Kwant’s build.conf under 'libraries'.
Christoph
participants (2)
-
Christoph Groth -
Etienne Fayen