Building/Running 3D slicer with Slicer_SUPERBUILD=OFF

Hi everyone,

I’ve managed to build 3DSlicer without the super-build mode by packaging/installing some of the underlying libraries for my Linux OS (Gentoo) and using some of the system libraries. After setting up the LD_LIBRARY_PATH and PYTHONPATH variables I’m able to start 3DSlicer but I get this error:

Traceback (most recent call last):
  File "/usr/lib/Slicer-4.8/qt-scripted-modules/DICOM.py", line 41, in __init__
    if slicer.mrmlScene.GetTagByClassName( "vtkMRMLScriptedModuleNode" ) != 'ScriptedModule':
AttributeError: 'vtkCommonCorePython.vtkObject' object has no attribute 'GetTagByClassName'
qSlicerPythonCppAPI::instantiateClass  - [ "DICOM" ] - Failed to instantiate scripted pythonqt class "DICOM" 0x7fb2fd398db8 
Fail to instantiate module  "DICOM" 

The symbol GetTagByClassName seems to have been built:

find -name "*.so" -exec nm --print-file-name {} \; | grep GetTagByClass

./bin/libMRMLCorePythonD.so:00000000001370e1 t _ZL32PyvtkMRMLScene_GetTagByClassNameP7_objectS0_
./bin/libMRMLCorePythonD.so:                 U _ZN12vtkMRMLScene17GetTagByClassNameEPKc
./bin/libqMRMLWidgets.so:                 U _ZN12vtkMRMLScene17GetTagByClassNameEPKc
./bin/libMRMLCore.so:0000000000550d0a T _ZN12vtkMRMLScene17GetTagByClassNameEPKc

Any ideas? Thanks in advance.

Best regards,
Rafael Palomar

This indicates that the python-wrapped slicer libraries aren’t being loaded (perhaps they aren’t in the path where expected) so the MRML nodes, which are vtkObject subclasses, are only seen as vtkObjects. Maybe easiest would be to compare you build layout to a SuperBuild layout and see where the differences are. Either adjust the directory tree or the launcher paths should make it workable.

the “Slicer_USE_SYSTEM_<packageName>” options

Not sure if this is something you already figure out but you can build Slicer by specifying Slicer_USE_SYSTEM_<packageName> option when configuring it for any of the project associated with an External_<packageName> found in the SuperBuild directory.

Looking at each individual SuperBuild/External_*.cmake file should also give some insight.

Using this approach will for example allow you to use VTKv9 on the system while ensuring the application launcher is downloaded and configured.

Also configuring with Slicer_USE_SYSTEM_VTKv9 set to ON will also automatically require python to be on the system and ensure the launcher settings are configured accordingly.

To conclude:

  • just starting Slicer using bin/SlicerApp-real is usually not recommended (unless you explicitly ensure the environment is correct).

  • I would also recommend against setting Slicer_USE_SUPERBUILD to OFF, instead prefer setting the Slicer_USE_SYSTEM_* options

Thank you @pieper and @jcfr for the tips. I’ll explore the alternatives you proposed; hopefully I can come up with a solution and post it here.

Best,
Rafael.

Hello,

I managed to build the packages in the superbuilld separately and get them installed. Then I also got 3D Slicer to build using the system libraries (I still have Slicer_USE_SUPERBUILD=OFF…having a superbuild was problematic for installing the packages). Now I am at the point where all dependences are installed in their own directory in /usr/lib64, in addition, 3D Slicer is installed in /usr.

Now the problem I’m facing is that when launching 3D Slicer (it does not matter if I use the launcher or just SlicerApp-real), required .so and .py libraries are not found. The problem is gone if I manually set PYTHONPATH and LD_LIBRARY_PATH.

Do you have any ideas on how to preserve the installation RPATH when building 3D Slicer?

Thanks in advance!

Best,
Rafael.

Thanks for the update :+1:

make install with superbuild

having a superbuild was problematic for installing the packages

You could run make install from Slicer-SuperBuild/Slicer-build

RPATH

preserve the installation RPATH when building 3D Slicer?

I suggest you look at https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling

PYTHONPATH

I manually set PYTHONPATH

The launcher settings are used by both the launcher and the application to set env. variable. For example, in a macOS package, the launcher settings are used. That way settings are consistently manage.

The same could be done on Linux.

If not already read by the launcher, here is where the launcher settings are loaded from the application:

Based on where the settings are installed on the system, we should tweak the following code: