Does anyone know if there is a way to statically build Slicer so that there is only one Slicer.exe and no vtkSlicer*.dll, qSlicer*.dll, vtkMRML*.dll or qMRML*.dll etc?
I tried configuring with BUILD_SHARED_LIBS=OFF, but it had no effect.
Thanks!
While this has been on my wish list, it is currently not supported.
To make progress, I suggest to start with python disabled, and only the minimum number of external projects.
To support loading the loadable modules, I anticipate that some header/cpp files would have to be generated to ensure the corresponding code is built in. On other hand, the CLI may be more complex … at first, they should probably be supported only when built as executable only.
If the use-case is improved start-up time, we could probably get a long way by reducing the total number of libraries (e.g. have libVTK, libITK, etc. rather than all the tiny constituents). When I’ve profiled start-up on mac, there is a huge amount of time spent in symbol coalescing (has to coalesce many external references, especially in ITK libraries, every time a CLI is pre-loaded).
Start-up time did seem to improve noticeably over the last months, though, so thanks to whoever (…@jcfr) did that 
Thanks Isaiah but it’s not about startup time. A client would like to make it harder to identify Slicer from the installed application files. I personally don’t think this would help a lot because you can look into the executable for the symbols, but still want to give this a try if I can.
You could strip or symbol-obfuscate a fully static build (which would presume a solution for dlopen’d libraries), but Python files would still be strongly identifying. There are tools like UPX which could essentially do whole-program obfuscation in a way that is simple and transparent enough that it might not break Slicer’s assumptions (basically decompresses at startup) but it would add startup overhead, and might be hard to justify in regulated situations.
1 Like
If you just want to change the appearance of the program to the casual user, you could probably use something like py2exe that would unpack and run behind the scenes and then cleans up afterwards (assuming startup time really isn’t an issue).
1 Like
Thanks for the ideas. Any tips for the original question though about how to statically build Slicer.exe? I need to use the installer too. If this is not considered enough then I’ll consider other methods later (to be honest I don’t think any amount of effort will be enough if a tech savvy person starts digging, but I’d like to fulfill the actual requests).
It’s been two years since this post. Is dynamic linking of libraries still the only option?
In the current way, I build some executables e.g. FiberTractMeasurements from SlicerDMRI and if I move Slicer build tree or the executables elsewhere, my executables can’t find libraries like:
/cli/FiberTractMeasurements: error while loading shared libraries: libSlicerBaseLogic.so: cannot open shared object file: No such file or directory
We currently do not actively support building Slicer main application statically.
If you would like to support using CLIs independently of Slicer, it should be possible to build them statically.
That said, since FiberTractMeasurements depends on Slicer libraries like MRMLCore (see here and here), ensuring the PATH and LD_LIBRARY_PATH env. variable are set will be the easiest.
To support this, you could for example install the SlicerDMRI extension, and then run the following command:
Slicer --launch FiberTractMeasurements
1 Like
Right, I know the last way. I shall try to see if SlicerDMRI can be built independently of Slicer. If nothing works, I shall probably write a Python version of FiberTractMeasurements 
I shall probably write a Python version of
FiberTractMeasurements
While possible, I think this would be counter productive.
I think we should better understand your use case and find way to support it. That way, we could work on improving the current infrastructure.
For example, we have been talking about factoring our MRML library so that they can be built independently and statically, and this could be prioritized.
Could you provide more details related to your use case? Which modules are you trying to use independently, in which environment, … ?
1 Like
What is the problem with starting the module by running Slicer --launch?
Technical problems, such as static/dynamic linking are issues that can be solved with small one-time efforts and so should not be significant factors in strategic decisions.
To decide if you want to reimplement some SlicerDMRI feature you may consider how much effort you and SlicerDMRI developers spend with adding new features, fixing bugs, importance of using exactly the same methods/getting exactly the same results, how much your long-term goals are aligned with goals and interests of SlicerDMRI developers. It may be also important what other current and future Slicer features you might use, etc.
1 Like