Even worse, they are compiler-specific. It should be possible to find the right set of options for each toolchain but it may require a lot of iterations. By the time we get everything right (safely work on most systems but not to degrade performance on current systems), most of the old computers may be decommissioned.
I’ve checked recent ITK changes and maybe they messed up something there that can be reverted without too much pain. I’ve reported the issue to their forum.
Did the discussion on ITK forum conclude for a course of action?
I’m testing a solution (setting ITK_*_OPTIMIZATION_FLAGS to empty in Slicer superbuild). Once I confirm that it works, I’ll send a pull request. Probably tomorrow.
Confirmed the fix works on Windows. Commited in rev28520.
I have the same issue recently:
Under Linux Mint 19.2 (Ubuntu 18.04), with Slicer trunk on 20191031
Here are what I trid:
But with no luck…
I ran:
./Slicer --launch mate-terminal
then in the term:
strace SlicerApp-real
I got ( the last part):
close(18) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, “/usr/lib/x86_64-linux-gnu/libssl.so.1.1”, O_RDONLY|O_CLOEXEC) = 18
read(18, “\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\325\1\0\0\0\0\0”…, 832) = 832
fstat(18, {st_mode=S_IFREG|0644, st_size=577312, …}) = 0
mmap(NULL, 2673024, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 18, 0) = 0x7fc2856d1000
mprotect(0x7fc285751000, 2097152, PROT_NONE) = 0
mmap(0x7fc285951000, 53248, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 18, 0x80000) = 0x7fc285951000
close(18) = 0
mprotect(0x7fc285951000, 36864, PROT_READ) = 0
munmap(0x7fc285e29000, 109229) = 0
futex(0x7fc285e27810, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7fc285e27804, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7fc285e278d8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7fc285e277f0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7fc285e277e8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7fc285e25c7c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7fc285e276c4, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7fc285e2765c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7fc285e27650, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7fc285e277fc, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7fc285e277b8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7fc285e277b0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
openat(AT_FDCWD, “/usr/lib/ssl/openssl.cnf”, O_RDONLY) = 18
fstat(18, {st_mode=S_IFREG|0644, st_size=10998, …}) = 0
read(18, “#\n# OpenSSL example configuratio”…, 4096) = 4096
read(18, “tableString, T61String (no BMPSt”…, 4096) = 4096
read(18, “eting an end user certificate as”…, 4096) = 2806
read(18, “”, 4096) = 0
close(18) = 0
futex(0x7fc285e277e0, FUTEX_WAKE_PRIVATE, 2147483647) = 0
— SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=NULL} —
+++ killed by SIGSEGV (core dumped) +++
Segmentation fault (core dumped)
Could I have some direction to try on?
Thanks!
Solved using ssl:
with the very same ( i think) environment, i tried to repeat the success in an adjacent folder, just to make sure I really got it right. But this time the building stopped in the middle due to the python site module problem.
And i just realized that even for the “success build” i have, it actually is not so right: the numpy is not loaded:
Traceback (most recent call last):
File “”, line 1, in
File “/media/pv/data/pv/usr/work/namic/rls20191029/Slicer-sb/python-install/lib/python3.6/imp.py”, line 170, in load_source
module = _exec(spec, sys.modules[name])
File “”, line 618, in _exec
File “”, line 678, in exec_module
File “”, line 219, in _call_with_frames_removed
File “/media/pv/data/pv/usr/work/namic/rls20191029/Slicer-sb/Slicer-build/lib/Slicer-4.11/qt-scripted-modules/DICOMScalarVolumePlugin.py”, line 1, in
import numpy
ModuleNotFoundError: No module named ‘numpy’
Traceback (most recent call last):
File “”, line 1, in
File “/media/pv/data/pv/usr/work/namic/rls20191029/Slicer-sb/python-install/lib/python3.6/imp.py”, line 170, in load_source
module = _exec(spec, sys.modules[name])
File “”, line 618, in _exec
File “”, line 678, in exec_module
File “”, line 219, in _call_with_frames_removed
File “/media/pv/data/pv/usr/work/namic/rls20191029/Slicer-sb/Slicer-build/lib/Slicer-4.11/qt-scripted-modules/Editor.py”, line 4, in
import EditorLib
File “/media/pv/data/pv/usr/work/namic/rls20191029/Slicer-sb/Slicer-build/lib/Slicer-4.11/qt-scripted-modules/EditorLib/init.py”, line 37, in
exec(“from .{0} import {0}Options, {0}Tool, {0}Logic, {0}”.format(effectName))
File “”, line 1, in
File “/media/pv/data/pv/usr/work/namic/rls20191029/Slicer-sb/Slicer-build/lib/Slicer-4.11/qt-scripted-modules/EditorLib/PaintEffect.py”, line 10, in
import numpy
ModuleNotFoundError: No module named ‘numpy’
Traceback (most recent call last):
File “”, line 1, in
File “/media/pv/data/pv/usr/work/namic/rls20191029/Slicer-sb/python-install/lib/python3.6/imp.py”, line 170, in load_source
module = _exec(spec, sys.modules[name])
File “”, line 618, in _exec
File “”, line 678, in exec_module
File “”, line 219, in _call_with_frames_removed
File “/media/pv/data/pv/usr/work/namic/rls20191029/Slicer-sb/Slicer-build/lib/Slicer-4.11/qt-scripted-modules/MultiVolumeImporterPlugin.py”, line 5, in
import vtk.util.numpy_support
File “/media/pv/data/pv/usr/work/namic/rls20191029/Slicer-sb/VTK-build/lib/python3.6/site-packages/vtkmodules/util/numpy_support.py”, line 31, in
import numpy
ModuleNotFoundError: No module named ‘numpy’
Traceback (most recent call last):
File “”, line 1, in
NameError: name ‘numpy’ is not defined
I’m investigating and will report back
I quickly run through this topic and I see that people build Slicer on their linux computer.
My question is ‘Why?’
I also run Slicer on a linux machine (LinuxMint 19.1) and I have never build it on that!
Just downloaded the linux package from the site, unpacked it in a folder called ‘Slicer’ and then run the executable ‘slicer’.
That’s it!
You have probably not used it long enough to say ‘Ooops! what’s happening ? Where is Slicer ?’. That happened twice to me, building it was the only way in these situations.
It is quite likely that the same Slicer binaries don’t work correctly on all Linux flavours and configurations, but I guess most Linux users chose the platform because they prefer to have more control over their systems and got used to building components on their own.
Yes, and those same Linux systems tend to have variability in compiler versions and directory layouts, so some build issues can be expected from time to time. It’s actually kind of remarkable that some much works well most of the time.
Ever thought about distributing Slicer as a Flatpak? 
https://flatpak.org/
Other software packages also use this (check it out for yourself).
coz i’m developing based on Slicer. that needs building from source.
Yes, and there’s also https://snapcraft.io/. Could be handy if anyone wants to take it on.
But realistically it hasn’t come up that often - the linux binaries we build seem to be pretty compatible with the distributions I use anyway.
by usnig strace SlicerApp-real, it seems that slicer is searching for libssl.so.1.1 in many places, with no luck.
However, in the entire superbuilld dir, i found ssl lib in:
./OpenSSL/libssl.so.1.0.0
Also in cmake, the default ssl version is 1.0.2n
I’m trying to see where in the process the 1.1 is requested…
Hi Steve, Hi Andras, @pieper @lassoan
I believed the problem on my machine was that python needs openssl 1.1.0 and up. I then upgraded openssl super build version to 1.1.1d. It then requires curl to be upgraded to 7.66, which I did, and it worked.
I believe this may be related with several recent issues:
Now I have a freshly built Slicer…
It is great that you were able to figure out all these and thank you very much for sharing the results.
@jcfr @Sam_Horvath Can you make the necessary changes in Slicer’s build system?
@gaoyi.cn Yes, nice work Yi! Is there a chance you could make a pull request with the needed changes?
Oops, I see you already made a PR https://github.com/Slicer/Slicer/pull/1245/files
@gaoyi.cn are these the right fixes? I’m curious why you closed it.
Hi Steve,
I recently did many test builds on different machines under different internet connection conditions. I believe the proposed changes does solve my problem. So I put them together and create a new pull request. Please advice.
Thanks!
yi