Slicer Build Environment Upgraded to `qt5-almalinux8-gcc14`

Development
, , ,
1

The build environment used for generating Slicer Preview and its extensions has been upgraded from qt5-centos7-gcc7 to qt5-almalinux8-gcc14.

This update brings improved C++ standards support, better compatibility with modern systems, and eliminates complications related to the Dual ABI issue previously discussed here.

Comparison of Build Environments

Build Environment Minimum Required glibc Manylinux Policy GCC Version Compatible Systems
qt5-centos7-gcc7 2.17 manylinux2014, manylinux_2_17 GCC 7 Debian 8+
Ubuntu 13.10+
Fedora 19+
RHEL 7+
qt5-almalinux8-gcc14 2.28 manylinux_2_28 GCC 14 Debian 10+
Ubuntu 18.10+
Fedora 29+
RHEL 8+

:warning: Important Note for Extension Developers :warning:

Due to Dual ABI issue referenced above, the extensions containing compiled C++ code (e.g., Loadable or CLI modules) built before July 23, 2025 using the older environment are not compatible with the updated Slicer Preview. Please rebuild your extensions to ensure compatibility.

2

Update:

To address remaining test failures on Linux systems using non-system Qt installations, the krb5-gssapi-stub project and its associated build option Slicer_BUILD_KRB5_GSSAPI_STUB have been introduced.

When enabled, this project builds a minimal libgssapi_krb5.so.2 stub library that exports only the GSS_C_NT_HOSTBASED_SERVICE symbol. This satisfies Qt5Network’s GSSAPI linkage requirements without introducing full Kerberos or OpenSSL system dependencies, which may conflict with those bundled with Slicer.

By default, the stub is automatically built only when:

  • The platform is Linux (i.e., UNIX AND NOT APPLE)
  • Slicer_USE_SYSTEM_QT is OFF (i.e., using a non-system Qt installation)
  • The Qt5::Network target reports gssapi as an enabled feature

This logic avoids building the stub unnecessarily and ensures compatibility when Qt has been installed via the Qt online installer or a custom prefix (which often links against Kerberos).

To override the default detection logic, developers can explicitly set the option:

-D Slicer_BUILD_KRB5_GSSAPI_STUB:BOOL=ON  # force build
-D Slicer_BUILD_KRB5_GSSAPI_STUB:BOOL=OFF # disable build

See PR-8598 (BUG: Add krb5-gssapi-stub to avoid GSSAPI runtime linkage issues on Linux)

1 Like
3

@jcfr could this update be the cause of this error “Error: could not load cache” on Linux for dcmqi, which started on Jul 22? SlicerPreview

I am not sure dcmqi is the only extension affected - SlicerRT started failing on Jul 22 as well: SlicerPreview

cc: @pieper

4

@jcfr I just wanted to report that I have the following issue on:

  • OS: Ubuntu 25.04

  • Compiler: GCC 14.2.0

  • CMake: 3.31.8

  • Qt: 5.15.2 (from online installer)

Problem: When launching Slicer, the following error occurs:

./Slicer /home/davide/Development/Slicer/Slicer-SuperBuild-Debug/Slicer-build/bin/./SlicerApp-real: symbol lookup error: /lib/x86_64-linux-gnu/libtirpc.so.3: undefined symbol: GSS_C_NT_USER_NAME, version gssapi_krb5_2_MIT

Root Cause: The system’s libtirpc.so.3 library conflicts with Slicer’s built-in GSS/Kerberos libraries, causing a symbol version mismatch.

Working Solutions:

  1. Remove Slicer’s GSS library (allows fallback to system library): rm /path/to/Slicer-build/bin/libgssapi_krb5.so*

  2. Disable GSS API stub during build: cmake -D Slicer_BUILD_KRB5_GSSAPI_STUB:BOOL=OFF …

Since there’s a working solution for the GSS_C_NT_USER_NAME symbol lookup error on Ubuntu 25.04, this isn’t a high-priority issue. However, it might be worth documenting this known compatibility issue and its workarounds in the official Slicer build instructions to help other users who encounter the same problem.

5

@fedorov, @jcfr, SlicerSOFA on Linux is also having the same issue. What sets these extensions apart is that they are Superbuild extensions. I have done a quick scan and found errors starting on July 22nd for other superbuild extensions (not the same error, though):

6

Can someone at Kitware confirm that the issue is not in some cache or something else leftover on the factory machines that need to be reset?

It is not the first time we have mysterious errors, and I think in the past there were cases when those were fixed by some magic by factory machines maintainers.

7

Thanks for bringing this up :folded_hands:, we will review :rocket: and follow-up.

For additional context, extension builds are orchestrated running the scripts maintained at Slicer/DashboardScripts

Beside of building the stable extensions against the existing Slicer Stable build tree having its site-packages directory restored daily, there is no additional caching.