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

**URL:** <https://discourse.slicer.org/t/slicer-build-environment-upgraded-to-qt5-almalinux8-gcc14/43802>\
**Category:** Development\
**Tags:** python, package, nightlybuild, extensions\
**Created:** [July 22, 2025, 5:19am UTC](https://discourse.slicer.org/t/slicer-build-environment-upgraded-to-qt5-almalinux8-gcc14/43802 "2025-07-22T05:19:42Z")\
**Posts on this page:** 13\
**Page:** 1

<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:** [July 22, 2025, 5:19am UTC](https://discourse.slicer.org/t/slicer-build-environment-upgraded-to-qt5-almalinux8-gcc14/43802/1 "2025-07-22T05:19:42Z")

</div>

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](https://discourse.slicer.org/t/temporary-disabling-of-stable-extension-builds-in-preparation-for-slicer-5-8-release-visual-studio-update/41207/7).

### 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+ |

### ⚠ Important Note for Extension Developers ⚠

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.

---

<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:** [July 24, 2025, 1:32pm UTC](https://discourse.slicer.org/t/slicer-build-environment-upgraded-to-qt5-almalinux8-gcc14/43802/2 "2025-07-24T13:32:19Z")

</div>

**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:

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

```

See [PR-8598](https://github.com/Slicer/Slicer/pull/8598) (BUG: Add krb5-gssapi-stub to avoid GSSAPI runtime linkage issues on Linux)

---

<div class="post-metadata">

**Author:** ![fedorov](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/fedorov/32/14_2.png) [@fedorov](https://discourse.slicer.org/u/fedorov)\
**Post date:** [August 5, 2025, 2:16am UTC](https://discourse.slicer.org/t/slicer-build-environment-upgraded-to-qt5-almalinux8-gcc14/43802/3 "2025-08-05T02:16:50Z")

</div>

@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](https://slicer.cdash.org/index.php?project=SlicerPreview&begin=2025-07-11&end=2025-08-01&filtercount=2&showfilters=1&filtercombine=and&field1=buildname&compare1=63&value1=dcmqi&field2=buildname&compare2=63&value2=-g%2B%2B)

I am not sure dcmqi is the only extension affected - SlicerRT started failing on Jul 22 as well: [SlicerPreview](https://slicer.cdash.org/index.php?project=SlicerPreview&begin=2025-07-11&end=2025-08-01&filtercount=2&showfilters=1&filtercombine=and&field1=buildname&compare1=63&value1=-g%2B%2B&field2=buildname&compare2=63&value2=slicerrt)

cc: @pieper

---

<div class="post-metadata">

**Author:** ![Davide\_Punzo](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/davide_punzo/32/66104_2.png) [@Davide\_Punzo](https://discourse.slicer.org/u/Davide_Punzo)\
**Post date:** [August 5, 2025, 8:14am UTC](https://discourse.slicer.org/t/slicer-build-environment-upgraded-to-qt5-almalinux8-gcc14/43802/4 "2025-08-05T08:14:07Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![RafaelPalomar](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/rafaelpalomar/32/1436_2.png) [@RafaelPalomar](https://discourse.slicer.org/u/RafaelPalomar)\
**Post date:** [August 8, 2025, 8:02am UTC](https://discourse.slicer.org/t/slicer-build-environment-upgraded-to-qt5-almalinux8-gcc14/43802/5 "2025-08-08T08:02:07Z")

</div>

> [@fedorov](#):
>
> @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](https://slicer.cdash.org/index.php?project=SlicerPreview&begin=2025-07-11&end=2025-08-01&filtercount=2&showfilters=1&filtercombine=and&field1=buildname&compare1=63&value1=dcmqi&field2=buildname&compare2=63&value2=-g%2B%2B)

@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):

- SlicerVMTK: [SlicerPreview](https://slicer.cdash.org/index.php?project=SlicerPreview&begin=2025-07-11&end=2025-08-01&filtercount=2&showfilters=1&filtercombine=and&field1=buildname&compare1=63&value1=vmtk&field2=buildname&compare2=63&value2=-g%252B%252B)
- SlicerOpenIGTLink: [SlicerPreview](https://slicer.cdash.org/index.php?project=SlicerPreview&begin=2025-07-11&end=2025-08-01&filtercount=2&showfilters=1&filtercombine=and&field1=buildname&compare1=63&value1=OpenIGTLink&field2=buildname&compare2=63&value2=-g%252B%252B)

---

<div class="post-metadata">

**Author:** ![fedorov](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/fedorov/32/14_2.png) [@fedorov](https://discourse.slicer.org/u/fedorov)\
**Post date:** [August 8, 2025, 3:10pm UTC](https://discourse.slicer.org/t/slicer-build-environment-upgraded-to-qt5-almalinux8-gcc14/43802/6 "2025-08-08T15:10:57Z")

</div>

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.

---

<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:** [August 8, 2025, 3:25pm UTC](https://discourse.slicer.org/t/slicer-build-environment-upgraded-to-qt5-almalinux8-gcc14/43802/7 "2025-08-08T15:25:10Z")

</div>

Thanks for bringing this up 🙏, we will review 🚀 and follow-up.

For additional context, extension builds are orchestrated running the scripts maintained at [Slicer/DashboardScripts](https://github.com/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_.

---

<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:** [August 26, 2025, 6:03pm UTC](https://discourse.slicer.org/t/slicer-build-environment-upgraded-to-qt5-almalinux8-gcc14/43802/8 "2025-08-26T18:03:30Z")

</div>

Several projects ([SlicerIGSIO](https://slicer.cdash.org/viewBuildError.php?buildid=3907129), [SlicerOpenIGTLink](https://slicer.cdash.org/viewBuildError.php?buildid=3907036), [SlicerANTs](https://slicer.cdash.org/viewBuildError.php?buildid=3907177), [SlicerRadiomics](https://slicer.cdash.org/viewBuildError.php?buildid=3907125)) have this error: `gmake[5]: *** read jobs pipe: Bad file descriptor. Stop.`.

This seems to be related to the toolchain, as these packages have no problems on Windows and macOS and did not have issues with previous Linux versions.

@jcfr @Sam_Horvath Could you have a look? Thank you!

---

<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:** [August 26, 2025, 9:29pm UTC](https://discourse.slicer.org/t/slicer-build-environment-upgraded-to-qt5-almalinux8-gcc14/43802/9 "2025-08-26T21:29:46Z")

</div>

The underlying image is being updated to include GNU Make 4.4 instead of GNU Make 4.2. We expect this to be completed either this evening or tomorrow.

---

<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:** [August 27, 2025, 10:07pm UTC](https://discourse.slicer.org/t/slicer-build-environment-upgraded-to-qt5-almalinux8-gcc14/43802/10 "2025-08-27T22:07:52Z")

</div>

The build environment has been updated to include GNU Make 4.4:

```auto
$ slicer-buildenv-qt5-almalinux8-gcc14-latest make --version
GNU Make 4.4
Built for x86_64-pc-linux-gnu

```

In addition of these updates, the following ones have been integrated:

- ninja: `1.11.1.g95dee.kitware.jobserver-1` → `1.13.1`
- automake `1.16` → `1.17`
- libtool `2.4.6` → `2.5.3`

---

<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:** [August 28, 2025, 1:04pm UTC](https://discourse.slicer.org/t/slicer-build-environment-upgraded-to-qt5-almalinux8-gcc14/43802/11 "2025-08-28T13:04:07Z")

</div>

To follow-up, the issue has not been fixed by the update of GNU Make, we will further investigate and report back.

---

<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 3, 2025, 10:25pm UTC](https://discourse.slicer.org/t/slicer-build-environment-upgraded-to-qt5-almalinux8-gcc14/43802/12 "2025-09-03T22:25:13Z")

</div>

Thanks to the insights of @Sam_Horvath and input of others during the last Slicer weekly meeting, we were able to identify the issues.

This should be fixed after integration the following pull request:

> <https://github.com/Slicer/Slicer/pull/8691>
>
> This pull request updates the build system to ensure the \`BUILD\_JOB\_SERVER\_AWARE…\` option is set for external projects when using CMake \>= 3.28. It addresses the \`gmake\[N\]: \*\*\* read jobs pipe: Bad file descriptor.\` issue associated with the build command.
> 
> 1. Modify \`ExternalProjectDependency.cmake\` to set \`BUILD\_JOB\_SERVER\_AWARE\`.
> 2. Update CTK configuration to ensure \`BUILD\_JOB\_SERVER\_AWARE\` is set.
> 3. Ensure this option is also set for extensions external projects
> 
> See https://discourse.slicer.org/t/slicer-build-environment-upgraded-to-qt5-almalinux8-gcc14/43802/8?u=jcfr

For more details:

- [ExternalProject: CMake 3.28.0 regressed INSTALL\_COMMAND+LOG\_INSTALL with GNU make (#26398) · Issues · CMake / CMake · GitLab](https://gitlab.kitware.com/cmake/cmake/-/issues/26398)
- [ExternalProject: Enable make job server with explicit build command (!8667) · Merge requests · CMake / CMake · GitLab](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8667)
- [execute\_process: Restore CLOEXEC on OUTPUT\_FILE and ERROR\_FILE descriptors (!10014) · Merge requests · CMake / CMake · GitLab](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/10014)

---

<div class="post-metadata">

**Author:** ![lkcl](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lkcl/32/80469_2.png) [@lkcl](https://discourse.slicer.org/u/lkcl)\
**Post date:** [December 16, 2025, 4:05pm UTC](https://discourse.slicer.org/t/slicer-build-environment-upgraded-to-qt5-almalinux8-gcc14/43802/13 "2025-12-16T16:05:20Z")

</div>

still present in Slicer-5.11.0-2025-12-15-linux-amd64
