As discussed in the 2025-01-25 Weekly Meeting, the builds of Slicer Stable extensions will be temporarily disabled this evening.
This step is necessary to facilitate updating the version of Visual Studio installed on the Windows factory (bluestreak). Once the Slicer 5.8 release is completed, this update will ensure that both Stable and Preview extensions are built using the same compiler, improving consistency across builds.
Next Steps:
Pause the build of Stable extensions (happening this evening).
Update Visual Studio on the Windows factory.
Wait for the January 21st preview build to complete.
Begin the release process for Slicer 5.8 on January 22nd.
We appreciate your patience and support during this process
@jcfr, thanks for informing. This is an important update.
Have there been any changes in the Linux build factory lately? I observe that the extension catalog is empty for the Linux preview since r33182 (https://extensions.slicer.org/catalog/All/33182/)
[...]
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19045.
-- The C compiler identification is MSVC 19.39.33523.0
-- The CXX compiler identification is MSVC 19.39.33523.0
[...]
After:
[...]
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19045.
-- The C compiler identification is MSVC 19.42.34436.0
-- The CXX compiler identification is MSVC 19.42.34436.0
[...]
Preview build manually triggered
To check that latest version of main build as expected (Slicer@87d3a309e), the build was manually triggered on the three platform based on these instructions.
We’ve identified the root cause of the crash occurring after installing binary Python wheels (e.g., ITK wheels). The issue stems from recent wheels being built with the newer std::string ABI, while the official Slicer and Python binaries target the older ABI. This mismatch leads to compatibility issues.
To resolve this, we plan to introduce an option that packages a _manylinux.py module specific to the build environment. This module will restrict the latest compatible version of GLIBC, ensuring compatibility with the host system.
For example, adding the following _manylinux.py module to the environment ensures compatibility with manylinux_2_17 or older wheels, avoiding the installation of newer, incompatible wheels like manylinux_2_28:
from typing import NamedTuple
class _GLibCVersion(NamedTuple):
major: int
minor: int
def manylinux_compatible(tag_major, tag_minor, tag_arch, **_): # PEP 600
if _GLibCVersion(tag_major, tag_minor) > _GLibCVersion(2, 17):
return False
return True
This ensures compatible wheels are installed on Ubuntu systems.
Later today, we’ll validate this solution by running the full SlicerMorph and SlicerANTs workflows. Once confirmed, we’ll integrate the fix into Slicer and proceed with the release process.
For now, Preview and Stable builds remain disabled.
To resolve this, we plan to introduce an option that packages a _manylinux.py module
The corresponding fix has been reviewed and integrated. For reference, see pull request Slicer#8168.
Add support for configuring _manylinux module
For convenience and future reference, the associated pull request description is also copied below:
This commit introduces the ability to configure a _manylinux module in the Slicer build system to enhance compatibility when installing binary Python wheels.
This update resolves potential issues with installing Python wheels built for newer GLIBC versions or ABIs, which could cause crashes in environments with older configurations.
Specifically, installing manylinux_2_28_x86_64 ITK wheels compiled with _GLIBCXX_USE_CXX11_ABI=1 was causing segmentation faults in the Stable Slicer version, which is compiled with _GLIBCXX_USE_CXX11_ABI=0. The _manylinux module ensures that manylinux_2_17_x86_64 ITK wheels are always installed, even when Slicer and its associated Python interpreter are executed on newer operating systems.
The _manylinux.py module is dynamically generated during the build process and ensures that Python packages installed via pip are compatible with the GLIBC version used in the Slicer build environment.
Summary of Changes
External_python.cmake:
Added logic to configure _manylinux.py for Linux-based build environments.
By default, _manylinux.py is generated. If disabled using the CMake option PYTHON_CONFIGURE_MANYLINUX_MODULE, any existing _manylinux.py module is removed to prevent inadvertent impacts on Python package installations.
Introduced a CMake option PYTHON_REMOVE_MANYLINUX_MODULE_IF_EXISTS to allow users to disable the removal of an existing _manylinux.py module.
python_configure_manylinux_module.cmake:
New CMake script to detect the system’s GLIBC version using ldd.
Dynamically generates the _manylinux.py module, which includes:
A manylinux_compatible function to override the default behavior of pip for checking compatibility of manylinux tags.
Embedded documentation and compatibility checks to prevent crashes caused by mismatched ABI or GLIBC versions.
By restricting installed packages to compatible manylinux tags, this update ensures stability and reliability for Python packages in the Slicer ecosystem.
For now, Preview and Stable builds remain disabled.