@pieper I asked because I was thinking about
_GLIBCXX_USE_CXX11_ABI=0
Does the issue happen in Slicer core with no extensions installed with its self-built VTK whl or does a Slicer extension install a specific VTK whl that pulls from PyPI that is using a different _GLIBCXX_USE_CXX11_ABI?
main ← jcfr:ensure-manylinux-abi-compat
opened 12:52AM - 24 Jan 25 UTC
This commit introduces the ability to configure a `_manylinux` module in the Sli… cer 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.
### References
- [PEP 600: Manylinux Platform Tag](https://peps.python.org/pep-0600/)
- [GCC Dual ABI Documentation](https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html)
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 .
Latest VTK on PyPI only provide x86_64 whls that are manylinux_2_17 as they provide manylinux_2_28 whl for ARM64 Linux only. vtk · PyPI