# Static build of Slicer

**URL:** <https://discourse.slicer.org/t/static-build-of-slicer/4011>\
**Category:** Development\
**Tags:** build\
**Created:** [September 6, 2018, 11:57pm UTC](https://discourse.slicer.org/t/static-build-of-slicer/4011 "2018-09-06T23:57:25Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![cpinter](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/cpinter/32/7995_2.png) [@cpinter](https://discourse.slicer.org/u/cpinter)\
**Post date:** [September 6, 2018, 11:57pm UTC](https://discourse.slicer.org/t/static-build-of-slicer/4011/1 "2018-09-06T23:57:25Z")

</div>

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!

---

<div class="post-metadata">

**Author:** ![jcfr](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jcfr/32/17825_2.png) [@jcfr](https://discourse.slicer.org/u/jcfr)\
**Post date:** [September 7, 2018, 5:09am UTC](https://discourse.slicer.org/t/static-build-of-slicer/4011/2 "2018-09-07T05:09:21Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ihnorton](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/ihnorton/32/9_2.png) [@ihnorton](https://discourse.slicer.org/u/ihnorton)\
**Post date:** [September 7, 2018, 1:54pm UTC](https://discourse.slicer.org/t/static-build-of-slicer/4011/3 "2018-09-07T13:54:48Z")

</div>

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 ✨

---

<div class="post-metadata">

**Author:** ![cpinter](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/cpinter/32/7995_2.png) [@cpinter](https://discourse.slicer.org/u/cpinter)\
**Post date:** [September 7, 2018, 2:07pm UTC](https://discourse.slicer.org/t/static-build-of-slicer/4011/4 "2018-09-07T14:07:41Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ihnorton](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/ihnorton/32/9_2.png) [@ihnorton](https://discourse.slicer.org/u/ihnorton)\
**Post date:** [September 7, 2018, 2:26pm UTC](https://discourse.slicer.org/t/static-build-of-slicer/4011/5 "2018-09-07T14:26:22Z")

</div>

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](https://en.wikipedia.org/wiki/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.

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [September 7, 2018, 2:34pm UTC](https://discourse.slicer.org/t/static-build-of-slicer/4011/6 "2018-09-07T14:34:08Z")

</div>

If you just want to change the appearance of the program to the casual user, you could probably use something like [py2exe](http://www.py2exe.org/index.cgi/Py2Exe) that would unpack and run behind the scenes and then cleans up afterwards (assuming startup time really isn’t an issue).

---

<div class="post-metadata">

**Author:** ![cpinter](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/cpinter/32/7995_2.png) [@cpinter](https://discourse.slicer.org/u/cpinter)\
**Post date:** [September 7, 2018, 8:10pm UTC](https://discourse.slicer.org/t/static-build-of-slicer/4011/7 "2018-09-07T20:10:10Z")

</div>

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).

---

<div class="post-metadata">

**Author:** ![tbillah](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/tbillah/32/4139_2.png) [@tbillah](https://discourse.slicer.org/u/tbillah)\
**Post date:** [January 13, 2021, 10:39pm UTC](https://discourse.slicer.org/t/static-build-of-slicer/4011/8 "2021-01-13T22:39:28Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![jcfr](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jcfr/32/17825_2.png) [@jcfr](https://discourse.slicer.org/u/jcfr)\
**Post date:** [January 13, 2021, 10:54pm UTC](https://discourse.slicer.org/t/static-build-of-slicer/4011/9 "2021-01-13T22:54:44Z")

</div>

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](https://github.com/SlicerDMRI/SlicerDMRI/blob/366d232d8406479fe2ec9fbd391d55978c2dfc11/Modules/CLI/FiberTractMeasurements/CMakeLists.txt#L15-L16) and [here](https://github.com/SlicerDMRI/SlicerDMRI/blob/366d232d8406479fe2ec9fbd391d55978c2dfc11/Modules/CLI/FiberTractMeasurements/FiberTractMeasurements.cxx#L29-L41)), 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:

```auto
Slicer --launch FiberTractMeasurements

```

---

<div class="post-metadata">

**Author:** ![tbillah](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/tbillah/32/4139_2.png) [@tbillah](https://discourse.slicer.org/u/tbillah)\
**Post date:** [January 13, 2021, 10:56pm UTC](https://discourse.slicer.org/t/static-build-of-slicer/4011/10 "2021-01-13T22:56:52Z")

</div>

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` 😃

---

<div class="post-metadata">

**Author:** ![jcfr](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/jcfr/32/17825_2.png) [@jcfr](https://discourse.slicer.org/u/jcfr)\
**Post date:** [January 13, 2021, 11:01pm UTC](https://discourse.slicer.org/t/static-build-of-slicer/4011/11 "2021-01-13T23:01:47Z")

</div>

> 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, … ?

---

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [January 14, 2021, 12:56am UTC](https://discourse.slicer.org/t/static-build-of-slicer/4011/12 "2021-01-14T00:56:23Z")

</div>

> [@tbillah](#):
>
> Right, I know the last way

What is the problem with starting the module by running `Slicer --launch`?

> [@tbillah](#):
>
> I shall probably write a Python version of `FiberTractMeasurements`

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.