GOMP version issue via python 3.9.8 (agama 1.0)

[ddhendriks]

I am trying to install and run Agama on the clusters here in Surrey and for some reason I get the following issue:

IPython 8.18.1 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import agama

ImportError Traceback (most recent call last) Cell In[1], line 1 ----> 1 import agama

File /vol/ph/astro_code/dhendriks/pyenv/versions/3.9.8/envs/agama3.9.8/lib/python3.9/site-packages/agama/init.py:1 ----> 1 from .agama import # import everything from the C++ library 2 from .agama import version, doc # these two are not automatically imported 3 from .py.pygama import # and everything from the Python extension submodule

ImportError: /usr/lib/x86_64-linux-gnu/libgomp.so.1: version `GOMP_4.5' not found (required by /vol/ph/astro_code/dhendriks/pyenv/versions/3.9.8/envs/agama3.9.8/lib/python3.9/site-packages/agama/agama.so)

The problem likely lies on the side of the server not having the correct libraries, but I wonder if this issue has been encountered before.

[eugvas]

Hmm, it looks like a version clash in the operating system, namely the code is compiled with a newer GCC version (and hence newer OpenMP library) than the version of libomp found in the operating system by default. The setup script tries to compile a dummy program that uses openmp, and if this does not succeed, then it will not use openmp for the main code. But it actually does not try to execute this program (an oversight on my part), which I suspect would also produce the same error. Perhaps you could manually try this: create a file test.cpp with the following content #include <omp.h> int main() {} then run g++ test.cpp -o test.exe -fopenmp it should produce a file test.exe, try to run it, and also run ldd test.exe to see which libraries it links against. If it uses the same file /usr/lib/x86_64-linux-gnu/libgomp.so.1 as agama.so, and is compiled with the same version of gcc, then I expect it to fail with the same error message, and I'd consider this to be a problem with the OS installation.

[ddhendriks]

Hi Eugene,

Running the steps you suggest on the same system does not lead to an error whatsoever. The ldd results of test.cpp are:

[9:57:30] ➜  impulse_approximation git:(main) ✗ ldd test.exe
    linux-vdso.so.1 =>  (0x00007ffddcb52000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00002b7eb3828000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00002b7eb3baa000)
    libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00002b7eb3eb3000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00002b7eb40d5000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00002b7eb42eb000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00002b7eb4508000)
    /lib64/ld-linux-x86-64.so.2 (0x00002b7eb3600000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00002b7eb48d2000)

the ldd results for agama.so are:

[10:05:39] ➜  agama git:(master) ldd agama.so 
./agama.so: /usr/lib/x86_64-linux-gnu/libgomp.so.1: version `GOMP_4.5' not found (required by ./agama.so)
./agama.so: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.29' not found (required by ./agama.so)
    linux-vdso.so.1 =>  (0x00007ffc17bc2000)
    libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00002b99829ad000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00002b9982be5000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00002b9982e02000)
    libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00002b9983006000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00002b9983209000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00002b998358b000)
    libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00002b9983894000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00002b9983ab6000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00002b9983ccc000)
    /lib64/ld-linux-x86-64.so.2 (0x00002b9981c9e000)

Something probably of relevance:

• installing python on that server became somewhat of an issue (recompile with -fPIC etc). I used clang to do that and that seemed to have worked. Using clang to compile your suggested code does also not lead to an issue. The linked libraries to the clang-compiled test.cpp are:

[10:00:22] ➜  impulse_approximation git:(main) ✗ ldd test.exe 
    linux-vdso.so.1 =>  (0x00007ffe06b30000)
    libomp.so.5 => /usr/lib/x86_64-linux-gnu/libomp.so.5 (0x00002b5d58993000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00002b5d58c5f000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00002b5d58e7c000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00002b5d59246000)
    /lib64/ld-linux-x86-64.so.2 (0x00002b5d5876b000)

[eugvas]

my next guess is that setup.py uses a different (newer) version of GCC than the system default. It receives the compiler name from Python itself, so it may be different from what you get by running g++. Here is an extract from setup.py that determines the compiler, followed by printing out its full path and version.

import subprocess
from distutils.ccompiler import new_compiler
CC = new_compiler().compiler_cxx
if isinstance(CC, list): CC = CC[0]
if   CC=='cc':    CC='c++'
elif CC=='gcc':   CC='g++'
elif CC=='clang': CC='clang++'
print(CC)
subprocess.call('which '+CC, shell=True)
subprocess.call(CC+' -v', shell=True)

Is is different from what you get by running which g++? You may also explicitly override the compiler by setting the environment variable CXX=... and running setup.py again, it should pick up your setting.