Slicer --version
Slicer 5.8.1-2025-03-02
SwissSkullStripper
Last update: Mon Mar 03 2025 4257d72
Any more information required?
This is discussed here:
@RafaelPalomar @jcfr do you have any ideas for this?
I use Arch Linux, if I can run some tests just let me know
are you also using Slicer 5.8.1-2025-03-02 ? If so, that is odd that I am experiencing it and not you. Unless there is an extra library that should be marked as required? https://aur.archlinux.org/packages/3dslicer
With Slicer 5.8.1 r33241 / 11eaf62 from the official Slicer download site, which is only repacked by the AUR PKGBUILD, SwissSkullStripper 4257d72 (2025-03-03) runs without errors on Arch. Slicer is not in /opt but in $HOME. How do you install an extension in /opt ?
I guessthe reason is because Slicer is compiled with -Slicer_STORE_SETTINGS_IN_APPLICATION_HOME_DIR=OFF
@hoteh, @lassoan I’m not very surprised extensions cause problems. The 3dslicer package is not a repackaged 3D Slicer binary, but a locally built one. Binary extensions are currently built on an old CentOS environment with gcc-7. This is far too different from the bleeding edge environment that arch provides with gcc-13. The SwissSkullStripper probably won’t be the only extension crashing. We experienced the same issue with the flatpak experience; we managed to get a flatpak version of Slicer, but extensions (some) will crash.
@hoteh, I have tried the official 3D Slicer binary with the SwissSkullStripper extension and seems to work fine.
I had an issue with the install path when installing the binary 3dslicer-bin, but when installing from source, 3dslicer it appears to install in the proper path. As per the doc Getting Started — 3D Slicer documentation that makes sense. There is an explicit warning against using 3dslicer-bin for that reason.
I could try installing 3dslicer-bin, and then giving write permision to /opt/3dslicer (I did that for freesurfer).
SOLVED!
I installed 3dslicer-bin, added write permissions to /opt/3dslicer, and all is well.