Open3d worked within slicer until revision 29392

SlicerMorph has the open3d==0.9.0 dependency, which was working well within Slicer (Linux) until revision 29392 came along. The last revision in which it worked was 29389.
Now, it throws out the following error:

Traceback (most recent call last):
File “/home/maga/.config/NA-MIC/Extensions-29402/SlicerMorph/lib/Slicer-4.11/qt-scripted-modules/”, line 51, in init
import open3d as o3d
ModuleNotFoundError: No module named ‘open3d’
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File “/home/maga/.config/NA-MIC/Extensions-29402/SlicerMorph/lib/Slicer-4.11/qt-scripted-modules/”, line 57, in init
import open3d as o3d
File “/home/maga/Downloads/Slicer-4.11.20200930-linux-amd64/lib/Python/lib/python3.6/site-packages/open3d/”, line 35, in
from .open3d import * # py2 py3 compatible
ImportError: /lib64/ version `CXXABI_1.3.8’ not found (required by /home/maga/Downloads/Slicer-4.11.20200930-linux-amd64/lib/Python/lib/python3.6/site-packages/open3d/
qSlicerPythonCppAPI::instantiateClass - [ “ALPACAWidget” ] - Failed to instantiate scripted pythonqt class “ALPACAWidget” 0x25e32f8
Warning, the module “ALPACA” has no widget representation
Warning, there is no UI for the module “ALPACA”

The key problem seems to be associated with this line:
ImportError: /lib64/ version `CXXABI_1.3.8’ not found

I looked at the commits around that time and couldn’t see anything that would justify this error. Any ideas?

Sounds like that’s related to a change in the open3d binary version itself. Did you try pip_installing it on an earlier version of Slicer?

Yeah…it works fine on Slicer revision 29389

Since I am using pip archived versions (from late 2019), shouldn’t the source of the issue be change within Slicer itself ? If I can pip install the same open3d version on Slicer revision 29389, but not on Slicer revision 29392, wouldn’t that suggest that some change within Slicer caused the break?

There does not seem to be any commits that could cause the ABI incompatibility issue. It is more likely to be caused by build toolset or configuration update on the Linux factory machine.

@Sam_Horvath was there any update or configuration change on the Linux factory machine around September 28?

Updating to a more recent version of open3d or building open3d locally might solve the problem.

1 Like

The factory image was updated to support Qt. 5.15.1 This is all that changed in our Dockerfile, but would have pulled the latest upstream images:

Notable changes in upstream:

Nothing should have changed about the toolset however, just the package source.


Dear Sam and Andras,
Thanks for checking it out. We haven’t figure out yet what is the source of the problem, but these links will give us a good starting point.
Thanks again,

It seems that Open3D developers deliberately choose an old C++ ABI. This page may contain useful information:

1 Like

Yeah, that is where I am as well. I was trying to build a manylinux wheel with a different ABI that would work across a broad range of linux flavors, but it still doesn’t seem to solve the problem (or I messed up somewhere). The error I shared yesterday was captured by Murat on a CentOs machine. But on my ubuntu laptop I don’t actually get any error in the error log. Slicer simply crashes and the last entry in the error log is the ‘Welcome’ screen entry. Interestingly, if I open SlicerPython (ie., without a GUI), I can import open3d with no problems. It seems that the source of the problem only occurs when loading the UI. Which again might indicate that something about the Qt upgrade was really the source of the issue.

The “good” news is that it doesn’t seem to impact Mac OSX and Windows. It is a linux-specifc problem.

1 Like

Yes, Windows is using Universal C Runtime since 2015, which preserves ABI compatibility across all versions. One less thing that can break.