Installing extension from Linux build

Hello,

I recently switched from Mac to Linux, so I downloaded the stable Linux release (4.8.1). I’m not as familiar with Linux, so I don’t know how to add extensions. With the Mac version I could load the GUI and do it that way, but I’m having trouble getting the SwissSkullStripping tool on the Linux build.

Thank you for the assistance.

Dan

The extension interface should be the same on mac/linux. 4.8.1 extensions look good to me…

Oh, okay, I was now able to run the GUI and install the SwissSkullStripper extension. I added this to my path, but when I went to run SwissSkullStripper on the command line, I received the following error:

SwissSkullStripper: error while loading shared libraries: libSwissSkullStripperLib.so: cannot open shared object file: No such file or directory

This is what I tried on the command line:

SwissSkullStripper --atlasMRI atlas_with_skull.nii.gz --atlasMask atlas_no_skull_mask.nii.gz input_data.nii.gz output_brain_no_skull.nii.gz output_mask_no_skull.nii.gz

And this is where I’m calling it from:
export PATH="/.config/NA-MIC/Extensions-26813/SwissSkullStripper/lib/Slicer-4.8/cli-modules/:$PATH"

Is there some step I’m missing that’s causing the error?

Actually, never-mind. I changed my LD_LIBRARY_PATH variable, and that seemed to solve the issue.

To run a CLI module outside Slicer, you need to use the launcher, which sets up all necessary shared library paths. Something similar to this should work (you might need to specify full or relative path for the module executable):

Slicer --launch SwissSkullStripper --atlasMRI atlas_with_skull.nii.gz --atlasMask atlas_no_skull_mask.nii.gz input_data.nii.gz output_brain_no_skull.nii.gz output_mask_no_skull.nii.gz
1 Like

I am trying to install manually a packaged CLI c++ extension, as described here https://www.slicer.org/wiki/Documentation/Nightly/Developers/FAQ#How_to_manually_install_an_extension_package.3F , but I am getting the same error as @dlevitas. The issue is “resolved” when I set LD_LIBRARY_PATH to the extension path. Why it behaves like this? Is there any other how to fully manually install a packaged extension without setting this environment variable?

Do you have problems running CLI modules from the command-line or modules do not show up in Slicer?

I am calling CLI module from another scripted module, but without setting that LD_LIBRARY_PATH the CLI module is not loaded (the command line, during Slicer app startup, displays the same error message as in @dlevitas case - error while loading shared libraries )

Could you please try with latest stable and nightly versions as well?

Have you downloaded the extension package from the Slicer appstore or you have built it yourself?

Does it work well with online installation (downloading and installing directly from the extension manager)?

I have tried to run it with the latest stable and nightly versions but the result is still the same.
FIX: The error message does not show up during Slicer startup but when the CLI module is called.

The error message is following:

/path.../Slicer4101/TestExtension- packaged/7d48c57-linux-amd64-TestExtension-local0-0000-00-00/lib/Slicer-4.10/cli-modules/TestCLIModule: error while loading shared libraries: libTestCLIModuleLib.so: cannot open shared object file: No such file or directory

I am trying to install CLI module which I am implementing myself. It is built using https://github.com/Slicer/SlicerBuildEnvironment exactly slicer/buildenv-qt5-centos7:slicer-4.10 with the following cmake parameters:

sudo ~/bin/slicer-buildenv-qt5-centos7-slicer-4.10 cmake \
  -BSlicer-build -HSlicer \
  -GNinja \
  -DCMAKE_BUILD_TYPE:STRING=Release \
  -DSlicer_USE_PYTHONQT_WITH_TCL:BOOL=OFF \
  -DSlicer_BUILD_CLI:BOOL=OFF \
  -DSlicer_USE_SimpleITK:BOOL=OFF \
  -DBUILD_TESTING:BOOL=OFF \
  -DQt5_DIR:PATH=./Qt5

(side note, offtopic: I was not sure about how to set Qt5 path properly inside docker container, so I used locally installed Qt5)

I tried to download and install randomly selected extension from extension manager (SwissSkullStripper) and everything works all fine, but I don’t know which type module it is so it maybe does not prove anything.

Compare the zip file that you download from the appstore with the zip file that you generate. Are there any differences in the directory structure, file names, or content of non-binary files?

You can find examples of docker images that include some additional extensions: GitHub - pieper/SlicerDockers: docker config files for slicer

If you want to build a custom Slicer package that comes with a few bundled extensions then it may be better to build a custom application.

I am not sure how to download an extension from the extension manager directly - to get the zip file. But checking the module import paths in the application settings it looks it is probably the same as the one I built and packaged.

SwissSkullStripper CLI module import path:

~/.config/NA-MIC/Extensions-27931/SwissSkullStripper/lib/Slicer-4.10/cli-modules

My custom CLI module import path:

.../lib/Slicer-4.10/cli-modules

And the content looks, in my eyes, very much the same:

-rwxr-xr-x 1 usrname 1792320 dub 26 00:26 libTestCLIModuleLib.so
-rwxr-xr-x 1 usrname   12800 dub 26 00:26 TestCLIModule
-rw-r--r-- 1 usrname    2262 dub 26 00:15 TestCLIModule.xml

Note, the module seems to be registered - it is present in slicer.modules.MODULE_NAME and when calling the CLI module cmd output include lines “TestCLIModule standard error:” then the error message I posted earlier, and finally “TestCLIModule completed with errors” afterward.

Anyway, thanks for providing links to custom Slicer package creation. But, it this case, if there is any other working way I would prefer distributing the modules separately.

Open this URL: @KitwareMedical/slicer-extensions-webapp (replacing revision as needed) then click Download. It is very important to know if there are any differences, even very small differences (4.10 vs 4.11) may break things.

I don’t think you can reliably distribute modules separately (to be used with Slicer executable that someone else creates) due to potential ABI incompatibility issues.

Checking the extension structure for specific revision no and the folder structure and files still look similar.

SwissSkullStripper

./27931-linux-amd64-SwissSkullStripper-git317d74d-2018-01-22
├── lib
│   └── Slicer-4.10
│       ├── cli-modules
│       │   ├── libSwissSkullStripperLib.so
│       │   ├── SwissSkullStripper
│       │   ├── SwissSkullStripperDefaultAtlas
│       │   │   ├── atlasImage.mha
│       │   │   └── atlasMask.mha
│       │   └── SwissSkullStripper.xml
│       └── qt-scripted-modules
│           ├── Resources
│           │   └── Icons
│           │       ├── AtlasImage.png
│           │       └── AtlasMask.png
│           ├── SwissSkullStripperSampleData.py
│           └── SwissSkullStripperSampleData.pyc
└── share
    └── Slicer-4.10
        └── SwissSkullStripper.s4ext

My custom CLI module

./7d48c57-linux-amd64-TestExtension-local0-0000-00-00
├── lib
│   └── Slicer-4.10
│       └── cli-modules
│           ├── libTestCLIModuleLib.so
│           ├── TestCLIModule
│           └── TestCLIModule.xml
└── share
    └── Slicer-4.10
        └── TestExtension.s4ext

Speaking about possible ABI compatibility issues, I thought that it can be overcome using Docker predefined images - if they are the same as used for official builds.