GNU/Linux systems

The instructions to build Slicer for GNU/Linux systems are slightly different depending on the Linux distribution and the specific configuration of the system. In the following sections, you can find instructions that will work for some of the most common Linux distributions in their standard configuration. If you are using a different distribution, you can use these instructions to adapt the process to your system. You can also ask questions related to the building process in the Slicer forum.

Checkout Slicer source files

The recommended way to obtain the source code of Slicer is cloning the repository using git:

git clone https://github.com/Slicer/Slicer.git

This will create a Slicer directory containing the source code of Slicer. Hereafter we will call this directory the source directory.

Tip

It is highly recommended to avoid the use of the space character in the name of the source directory or any of its parent directories.

After obtaining the source code, we need to set up the development environment:

cd Slicer
./Utilities/SetupForDevelopment.sh
cd ..

Configure and generate the Slicer build project files

Slicer is highly configurable and multi-platform. To support this, Slicer needs a configuration of the build parameters before the build process takes place. In this configuration stage, it is possible to adjust variables that change the nature and behavior of its components. For instance, the type of build (Debug or Release mode), whether to use system-installed libraries, let the build process fetch and compile own libraries, or enable/disable some of the software components and functionalities of Slicer.

The following folders will be used in the instructions below:

Folder	Path
source	`~/Slicer`
build	`~/Slicer-SuperBuild-Debug`
inner-build	`~/Slicer-SuperBuild-Debug/Slicer-build`

To obtain a default configuration of the Slicer build project, create the build folder and use cmake:

mkdir Slicer-SuperBuild-Debug
cd Slicer-SuperBuild-Debug
cmake ../Slicer

It is possible to change variables with cmake. In the following example we change the built type (Debug as default) to Release:

cmake -DCMAKE_BUILD_TYPE:STRING=Release ../Slicer

Qt 5

If Qt5 was installed from the Qt Company online installer, the CMake variable Qt5_DIR must be set:

cmake -DCMAKE_BUILD_TYPE:STRING=Release -DQt5_DIR:PATH=/opt/qt/5.15.2/gcc_64/lib/cmake/Qt5 ../Slicer

Note

On Ubuntu 25.10 (GCC 15), add -DADDITIONAL_C_FLAGS=-std=gnu11 to work around a C23 incompatibility in ITK’s MINC library:

cmake -DCMAKE_BUILD_TYPE:STRING=Release -DADDITIONAL_C_FLAGS=-std=gnu11 ../Slicer

Qt 6

To build with Qt6, set -DQt6_DIR pointing to the Qt6 cmake directory. Slicer will automatically enforce the minimum required Qt6 version (6.8). When using distribution-provided Qt6 packages (e.g. Ubuntu 25.10), Qt6_DIR is typically /usr/lib/x86_64-linux-gnu/cmake/Qt6:

cmake \
  -DCMAKE_BUILD_TYPE:STRING=Release \
  -DQt6_DIR:PATH=/usr/lib/x86_64-linux-gnu/cmake/Qt6 \
  ../Slicer

Note

On Ubuntu 25.10 (GCC 15), add -DADDITIONAL_C_FLAGS=-std=gnu11 to work around a C23 incompatibility in ITK’s MINC library:

cmake \
  -DCMAKE_BUILD_TYPE:STRING=Release \
  -DADDITIONAL_C_FLAGS=-std=gnu11 \
  -DQt6_DIR:PATH=/usr/lib/x86_64-linux-gnu/cmake/Qt6 \
  ../Slicer

If Qt6 was installed from the Qt Company online installer, set Qt6_DIR to the installer location instead:

cmake \
  -DCMAKE_BUILD_TYPE:STRING=Release \
  -DQt6_DIR:PATH=/opt/qt/6.8.0/gcc_64/lib/cmake/Qt6 \
  ../Slicer

Warning

On distributions shipping Qt6 < 6.8 (e.g. Debian 12, Ubuntu 24.04), the cmake configure step will fail with a version error. To bypass the check and build anyway — at your own risk and without official support — explicitly set Slicer_REQUIRED_QT_VERSION=6.4:

cmake \
  -DCMAKE_BUILD_TYPE:STRING=Release \
  -DSlicer_REQUIRED_QT_VERSION=6.4 \
  -DQt6_DIR:PATH=/usr/lib/x86_64-linux-gnu/cmake/Qt6 \
  ../Slicer

Warning

On Debian 12 Bookworm (Stable), the included OpenSSL version (3.0.x) is not compatible with the OpenSSL versions (1.0 - 1.1) used in Slicer, and attempting to run Slicer will emit the following warning, indicating that SSL support is disabled:

qt.network.ssl: Incompatible version of OpenSSL (built with OpenSSL >= 3.x, runtime version is < 3.x)
[SSL] SSL support disabled - Failed to load SSL library !
[SSL] Failed to load Slicer.crt
QSslSocket::connectToHostEncrypted: TLS initialization failed

To enable SSL, one can use the system OpenSSL as follows:

cmake -DSlicer_USE_SYSTEM_OpenSSL=ON ../Slicer

Tip – Interfaces to change 3D Slicer configuration variables

Instead of cmake, one can use ccmake, which provides a text-based interface, or cmake-gui, which provides a graphical user interface. These applications will also provide a list of variables that can be changed.

Tip – Speed up 3D Slicer build with ccache

ccache is a compiler cache that can speed up subsequent builds of 3D Slicer. This can be useful if 3D Slicer is built often and there are no large divergences between subsequent builds. This requires ccache installed on the system (e.g., sudo apt install ccache).

The first time ccache is used, the compilation time can marginally increase as it includes the first caching. After the first build, subsequent build times will decrease significantly.

ccache is not detected as a valid compiler by the 3D Slicer building process. You can generate local symbolic links to disguise the use of ccache as valid compilers:

ln -s /usr/bin/ccache ~/.local/bin/c++
ln -s /usr/bin/ccache ~/.local/bin/cc

Then, the Slicer build can be configured to use these compilers:

cmake \
  -DCMAKE_BUILD_TYPE:STRING=Release \
  -DCMAKE_CXX_COMPILER:STRING=$HOME/.local/bin/c++ \
  -DCMAKE_C_COMPILER:STRING=$HOME/.local/bin/cc \
  ../Slicer

Build Slicer

Once the Slicer build project files have been generated, the Slicer project can be built by running this command in the build folder

make

Tip – Parallel build

Building Slicer will generally take a long time, particularly on the first build or upon code/configuration changes. To help speed up the process, one can use make -j<N>, where <N> is the number of parallel builds. As a rule of thumb, many use the number of CPU threads - 1 as the number of parallel builds.

Warning

Increasing the number of parallel builds generally increases the memory required for the build process. In the event that the required memory exceeds the available memory, the process will either fail or start using swap memory, which may make the system freeze.

Tip – Error detection during parallel build

Using parallel builds makes finding compilation errors difficult due to the fact that all parallel build processes use the same screen output, as opposed to sequential builds, where the compilation process will stop at the error. A common technique to have parallel builds and easily find errors is to launch a parallel build followed by a sequential build. For the parallel build, it is advised to run make -j<N> -k to have the parallel build keep going as far as possible before doing the sequential build with make.

Run Slicer

After the building process has successfully completed, the executable file to run Slicer will be located in the inner-build folder.

The application can be launched by these commands:

cd Slicer-build
./Slicer`

Test Slicer

After building, run the tests in the inner-build folder.

Type the following (you can replace 4 with the number of processor cores in the computer):

ctest -j4

Package Slicer

Start a terminal and type the following in the inner-build folder:

make package

Common errors

See a list of issues common to all operating systems on the Common errors page.

GNU/Linux systems

Prerequisites

Debian 12 Bookworm (Stable)

Ubuntu 25.10 (Questing Quokka)

Ubuntu 24.04 (Noble Numbat)

Ubuntu 22.04 (Jammy Jellyfish)

ArchLinux

Any Distribution

Checkout Slicer source files

Configure and generate the Slicer build project files

Build Slicer

Run Slicer

Test Slicer

Package Slicer

Common errors