Hi, I’m trying to install PyGPlates on Ubuntu 20.04 and have followed all of the instructions in the readme files. I have checked and all dependencies are installed and I am able to build the pygplates.so image. However, when I try and import the module I get the error: “segmentation fault (core dumped)”. Does anyone know how to solve this?
Hi John, thanks for the reply. I installed pygplates using the focal.deb package that you recommended, and set the correct PYTHONPATH environment variable. However, when I try and import the module, I still get the same error “Segmentation fault (core dumped)”. It seems whichever way pygplates is installed, this error keeps occurring when I try and import the module on my system.
You mentioned previously not having the correct version of GDAL installed. I’ve only ever installed the system default versions (eg, using sudo apt install libgdal-dev). Maybe try installing the default version of boost (if you installed a different version) because I know that different platforms have had issues with seg faulting related to boost (ie, pygplates might not segfault on one OS/library version but will on another).
Hi, I have installed the correct versions of both libgdal-dev and boost and re-installed pygplates-py3 from Focal, however still cannot get past the same error of “Segmentation fault (core dumped)”. When I run the command that you have suggested, I get:
I have also noticed something else strange, when I import the pygmt module I get no errors. However, if I import this after importing pygplates, I get errors. This does not occur with any other module. I have included this below:
python3 -c “import pygplates; import pygmt”
Traceback (most recent call last):
File “”, line 1, in
File “/home/bhavik/anaconda3/envs/kinpy_forward/lib/python3.9/site-packages/pygmt/init.py”, line 70, in
_begin()
File “/home/bhavik/anaconda3/envs/kinpy_forward/lib/python3.9/site-packages/pygmt/session_management.py”, line 16, in begin
with Session() as lib:
File “/home/bhavik/anaconda3/envs/kinpy_forward/lib/python3.9/site-packages/pygmt/clib/session.py”, line 183, in enter
self.create(“pygmt-session”)
File “/home/bhavik/anaconda3/envs/kinpy_forward/lib/python3.9/site-packages/pygmt/clib/session.py”, line 329, in create
c_create_session = self.get_libgmt_func(
File “/home/bhavik/anaconda3/envs/kinpy_forward/lib/python3.9/site-packages/pygmt/clib/session.py”, line 281, in get_libgmt_func
self._libgmt = load_libgmt()
File “/home/bhavik/anaconda3/envs/kinpy_forward/lib/python3.9/site-packages/pygmt/clib/loading.py”, line 59, in load_libgmt
raise GMTCLibNotFoundError(“\n”.join(error_msg))
pygmt.exceptions.GMTCLibNotFoundError: Error loading GMT shared library at ‘/home/bhavik/anaconda3/envs/pygmt/lib/libgmt.so’.
/home/bhavik/anaconda3/envs/pygmt/lib/./libgdal.so.29: undefined symbol: opj_encoder_set_extra_options
Error loading GMT shared library at ‘libgmt.so’.
libgmt.so: cannot open shared object file: No such file or directory
Segmentation fault (core dumped)
I do not know why importing pygplates causes errors with pygmt, as it is not a dependency. However, I have included the information in case you have seen this issue before.
It looks like conflicting GDAL library versions. Since you’re using Anaconda the GDAL version built inside Anaconda is being used (/home/bhavik/anaconda3/envs/pygmt/lib/libgdal.so). However pygplates is compiled against the system GDAL (installed by sudo apt install libgdal-dev).
Try using the system version of python3 when running python3 -c "import pygplates" and see it if still seg faults. In other words don’t run that command within an Anaconda environment.
In the next release we plan to have an Anaconda version of pygplates, which should avoid this sort of problem.
When I try and import pygplates from the base environment I get the following:
python3 -c “import pygplates”
Traceback (most recent call last)
File “”, line 1, in
ImportError: /home/bhavik/anaconda3/bin…/lib/libQt5Core.so.5: version `Qt_5.12’ not found (required by usr/lib/pygplates/revision28/pygplates.so)
I guess this is the same problem, the anaconda Qt5 library is being loaded when pygplates needs the system version. I have the system versions of both GDAL QT5 installed, do you know how I can make pygplates use these versions instead of the anaconda versions? I have tried setting the environment variables but this doesn’t seem to work
I forgot to mention that conda usually activates the base environment by default. So it’s just another conda environment. Try running conda deactivate before running python3 -c "import pygplates". There’s also mention here how to prevent activating the base environment by default. So this is really just to test if pygplates works outside of conda.
When I deactivate the base environment and try and import pygplates, I get the following:
Traceback (most recent call last):
File “”, line 1, in
ImportError: libboost_program_options.so.1.72.0: cannot open shared object file: No such file or directory
So it seems to be different dependency issues no matter the conda environment or if not in a conda environment.
Hmm, not sure why that’s happening. Also my Ubuntu 20.04 uses boost 1.71 (and yours is looking for 1.72).
In any case, I think you’re wanting to use pygplates in a conda environment (so you can use conda packages at the same time) so the best bet for now is to compile pygplates using the dependencies in your conda environment. You can do that by following the instructions in this thread. In particular you can start with this post but also use conda’s cmake (mentioned in this post) and apply the patches mentioned in this post.
That should hopefully gets things working for you until the next pygplates release in the coming months (which will support conda).
So I followed all the instructions, including installing the dependencies into a new conda env, using conda cmake and making the changes to the cmake files etc. The installation runs without any errors and all paths are correct. However, the “Segmentation fault (core dumped)” error still comes no matter what I do…
Nice job compiling for conda. Can you PM me your CMakeCache.txt file? I just want to double-check that it’s using only conda dependencies (in particular GDAL, which is causing the seg fault).
As we discussed offline just now, your initial seg fault is now fixed (the problem mentioned in this post above: libgdal.so.29: undefined symbol: opj_encoder_set_extra_options). By compiling pygplates in conda, both pygplates and pygmt use the same version of GDAL (thus avoiding the conflict).
The problem you’re now having (mentioned in this post) is a different issue that’s covered in this post: it’s an issue with pygplates seg faulting on exit when using version 3.9 of Python that I’m currently looking into.
So now you’re compiling pygplates in a Python 3.8 (not 3.9) conda environment as a workaround.
So I created an anaconda environment with Python 3.8 and followed all of the instructions, editing the build files etc to make sure the correct version of GDAL is found. The build and installation ran without any errors, however when trying to import pygplates the following error comes up:
ImportError: libboost_python39.so.1.72.0: cannot open shared object file: No such file or directory
The file libboost_python39.so.1.72.0 does not exist, but the file libboost_python38.so.1.72.0 does exist and is installed in the same environment (called pygplates_py38) used for the build and installation, so I don’t know why the path is being directed elsewhere…
It’s probably a leftover reference from your previous pygplates build in the Python 3.9 environment (if you’re building from the same pygplates source code directory for your Python 3.8 environment).
You can try removing the CMakeCache.txt file (as that caches all the build references, like libboost_python39.so.1.72.0). And then run 'cmake .' again. Then you can then double-check that the new CMakeCache.txt file no longer references Python 3.9 in any way. Then run make. That should compile quite quickly.
If that doesn’t work then try removing the entire pygplates source directory altogether (this should also remove your build artefacts if you built in the same directory, eg, with 'cmake .'). Then extract the source code again and repeat the build (run 'cmake .' followed by make). This will compile slowly (since it’s a full rebuild).
Hi John, I deleted the CMakeCache.txt file and the entire pygplates source directory and ran all the steps described in previous comments, using Python 3.8. However, the “Segmentation fault (core dumped)” error is still occurring…
It might be worth trying the new pyGPlates 0.35 source code mentioned in this post.
It fixes the seg fault on exit for Python 3.9 (but might also fix your Python 3.8 issue, if it’s the same problem, although I’ve only heard of this particular seg-fault-on-exit problem happening with Python 3.9).