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
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.
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
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?
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:
