We want to package the OpenCL ICD loader in particular in dependent remote modules.

We can build on the shared library support in 5.3rc1 for TBB.

For the platform-specific wheel fix-up tools, auditwheel (Linux), delocate (macOS), delvewheel (Windows) we need to add support for additional shared libraries. Mostly, this should be making the scripts that expose the path to local libraries with environmental variables allow appending to that variable, then set this variable to the path to the OpenCL ICD loader library in the remote module GitHub CI configuration.

E.g.:

https://github.com/InsightSoftwareConsortium/ITKPythonPackage/blob/ad3f8d0c3dcb0e1b959924b4ceea8e832d612758/scripts/internal/manylinux-build-module-wheels.sh#L14

->

export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:/work/oneTBB-prefix/lib64

For Windows:

https://github.com/InsightSoftwareConsortium/ITKPythonPackage/blob/ad3f8d0c3dcb0e1b959924b4ceea8e832d612758/scripts/windows_build_wheels.py#L225-L228

We may need to change this script to enable passing addition paths as a CLI argument. Also, we will likely need to adjust the strategy since delvewheel patches itk/__init__.py.

For macOS:

https://github.com/InsightSoftwareConsortium/ITKPythonPackage/blob/ad3f8d0c3dcb0e1b959924b4ceea8e832d612758/scripts/macpython-build-module-wheels.sh#L29

When attempting to install via the pip: pip install itk

I receive the following error:

ITK source code directory path length is too long (${n} > 50).
Please move the ITK source code directory to a directory with a shorter path.

According to this article (https://public.kitware.com/pipermail/community/2013-December/004475.html), the check is due to Visual Studio and truncation of commands.

Is there a way to specify the build and install directory? In addition, the build files in skbuild are fairly long as it is so I could only place the ITKPythonPackage directory in my D: drive for it to work.

If there is not a way to specify the build and install directory, I propose this option be added and documentation be added to the front page.

This commit is a follow-up of these commits:

• a5f774ba5 (ENH: Add TBB support to Linux wheels)
• 374c744a1 (ENH: Add macOS wheel TBB support)
• 037a326c1 (ENH: Build macOS module wheels with TBB support)

It ensures that oneTBB is built specifying the non-default options expected by oneTBB ^1 and it should ensure the library can be loaded on macOS >= 10.9.

See https://discourse.itk.org/t/itk-5-3rc4-post3-failure-to-load-libtbb-library-observed-on-macos-10-13/5405/1#suggested-path-forward-3

Interestingly, delocate-listdeps has recently started to fail when building module packages:

+/Users/Kitware/Dashboards/ITK/ITKPythonPackage/scripts/../venvs/2.7/bin/delocate-listdeps /Users/travis/build/InsightSoftwareConsortium/ITKRingArtifact/dist/itk_ringartifact-0.1.0-cp27-cp27m-macosx_10_6_x86_64.whl /Users/travis/build/InsightSoftwareConsortium/ITKRingArtifact/dist/itk_ringartifact-0.1.0-cp34-cp34m-macosx_10_6_x86_64.whl /Users/travis/build/InsightSoftwareConsortium/ITKRingArtifact/dist/itk_ringartifact-0.1.0-cp35-cp35m-macosx_10_6_x86_64.whl /Users/travis/build/InsightSoftwareConsortium/ITKRingArtifact/dist/itk_ringartifact-0.1.0-cp36-cp36m-macosx_10_6_x86_64.whl
/Users/travis/build/InsightSoftwareConsortium/ITKRingArtifact/dist/itk_ringartifact-0.1.0-cp27-cp27m-macosx_10_6_x86_64.whl:
Traceback (most recent call last):
  File "/Users/Kitware/Dashboards/ITK/ITKPythonPackage/scripts/../venvs/2.7/bin/delocate-listdeps", line 61, in <module>
    main()
  File "/Users/Kitware/Dashboards/ITK/ITKPythonPackage/scripts/../venvs/2.7/bin/delocate-listdeps", line 44, in main
    lib_dict = wheel_libs(path)
  File "/Users/kitware/Dashboards/ITK/ITKPythonPackage/venvs/2.7/lib/python2.7/site-packages/delocate/libsana.py", line 161, in wheel_libs
    lib_dict = tree_libs(tmpdir, filt_func)
  File "/Users/kitware/Dashboards/ITK/ITKPythonPackage/venvs/2.7/lib/python2.7/site-packages/delocate/libsana.py", line 54, in tree_libs
    for install_name in get_install_names(depending_libpath):
  File "/Users/kitware/Dashboards/ITK/ITKPythonPackage/venvs/2.7/lib/python2.7/site-packages/delocate/tools.py", line 173, in get_install_names
    if not _line0_says_object(lines[0], filename):
  File "/Users/kitware/Dashboards/ITK/ITKPythonPackage/venvs/2.7/lib/python2.7/site-packages/delocate/tools.py", line 143, in _line0_says_object
    raise InstallNameError('Unexpected first line: ' + line0)
delocate.tools.InstallNameError: Unexpected first line: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/objdump: '/private/var/folders/bb/n7t3rs157850byt_jfdcq9k80000gn/T/tmp_NF5m6/itk/itkFourierStripeArtifactImageFilterPython.py': The file was not recognized as a valid object file

CC: @jcfr @matthew-brett

Motivation for this change is to build wheels with C++ ABI compatible with Slicer built using newer g++ having _GLIBCXX_USE_CXX11_ABI defaulting to 1.

See https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html

Note that the latest Slicer release (5.0) is built using centos7 based ^1 environment having _GLIBCXX_USE_CXX11_ABI set to 0.

We should likely build wheels using both manylinux2014 and manylinux_2_28.

As of 2022.06.22, this pull-request uses 2_24, as commented ^2 by @henryiii, I will instead update dockcross ^3 to add 2_28 based image (instead of 2_24).

References:

• https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
• https://discuss.python.org/t/how-to-set-glibcxx-use-cxx11-abi-for-manylinux2014-and-manylinux2010-wheels/10551
• https://github.com/pytorch/pytorch/issues/51039
• https://github.com/pypa/manylinux/issues/1012
• https://github.com/dockcross/dockcross/pull/705

Unable to find itkHelpers.py in the installation and got python error: ModuleNotFoundError: No module named 'itkHelpers'

itk python 5.2.0 installed via pip install itk

my Env: win10 64 bits python 3.6 itk 5.1.0

my err: File "C:\Users\haoch\AppData\Local\Programs\Python\Python36\lib\site-packages\itk\Configuration..\ITKPyBasePython.py", line 15, in import _ITKPyBasePython ImportError: DLL load failed:

when I use itk.imread(path),then the error occured what can I do?

Summary

Local and CI tests in relation to https://github.com/InsightSoftwareConsortium/ITKPythonPackage/pull/233 fail to build on Linux. The issue appears to originate from the dockcross manylinux image.

Observed behavior

Building wheels for x64 using manylinux_2_28
++ type ninja
++ MANYLINUX_VERSION=_2_28
++ echo 'Building wheels for x64 using manylinux_2_28'
+ sudo ldconfig
/opt/rh/gcc-toolset-12/root/usr/bin/sudo: line 41: /usr/bin/sudo: No such file or directory
Error: Process completed with exit code 127.

See log: https://github.com/InsightSoftwareConsortium/ITKSplitComponents/actions/runs/3583756532/jobs/6029570633

Expected behavior

Build succeeds.

Steps to Reproduce

> MANYLINUX_VERSION=_2_28
> IMAGE_TAG=20221128-2024e4b

# Generate dockcross scripts
> docker run --rm dockcross/manylinux${MANYLINUX_VERSION}-x64:${IMAGE_TAG} > /tmp/dockcross-manylinux-x64
> chmod u+x /tmp/dockcross-manylinux-x64

# Launch container
> /tmp/dockcross-manylinux-x64 bash

# Try to run any command with sudo
>> sudo ldconfig
/opt/rh/gcc-toolset-12/root/usr/bin/sudo: line 41: /usr/bin/sudo: No such file or directory

# Try to find sudo in /usr/bin
>> ls /usr/bin | grep sudo
# no results

Other Notes

Possibly related to the most recent image tag update: https://github.com/InsightSoftwareConsortium/ITKPythonPackage/pull/230

Investigation shows that sudo works in the previous dockcross image:

> IMAGE_TAG=20221108-102ebcc
> docker run --rm dockcross/manylinux${MANYLINUX_VERSION}-x64:${IMAGE_TAG} > /tmp/dockcross-manylinux-x64
> chmod u+x /tmp/dockcross-manylinux-x64
> /tmp/dockcross-manylinux-x64 bash
>> sudo ldconfig
>> sudo echo "sudo works"
sudo works

Several related updates:

• Adds update step to apply build script patches to ITKPythonBuilds packages
• Exposes manylinux parameters and resolves issue where wrong image was used with specialized tarballs
• Reverts manylinux image tag while awaiting fix for sudo issue tracked in https://github.com/InsightSoftwareConsortium/ITKPythonPackage/issues/235 and https://github.com/dockcross/dockcross/issues/746

These changes are tested at https://github.com/InsightSoftwareConsortium/ITKSplitComponents/actions/runs/3586129456

Despite explicitly getting CMake 3.24 in the CI, an older version is used during some stage resulting in insufficient version error:

-- Configuring done
-- Generating done
-- Build files have been written to: /work/_cmake_test_compile/build
CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
  CMake 3.24 or higher is required.  You are running version 3.23.1


-- Configuring incomplete, errors occurred!
  File "/opt/python/cp38-cp38/lib/python3.8/site-packages/skbuild/setuptools_wrap.py", line 544, in setup
    env = cmkr.configure(cmake_args,
  File "/opt/python/cp38-cp38/lib/python3.8/site-packages/skbuild/cmaker.py", line 221, in configure
    raise SKBuildError(
An error occurred while configuring with CMake.
  Command:

    "cmake" "/work" "-G" "Ninja" "-DCMAKE_INSTALL_PREFIX:PATH=/work/_skbuild/linux-x86_64-3.8/cmake-install" "-DPYTHON_EXECUTABLE:FILEPATH=/opt/python/cp38-cp38/bin/python" "-DPYTHON_VERSION_STRING:STRING=3.8.13" "-DPYTHON_INCLUDE_DIR:PATH=/opt/_internal/cpython-3.8.13/include/python3.8" "-DPYTHON_LIBRARY:FILEPATH=libpython3.8.a" "-DSKBUILD:BOOL=TRUE" "-DCMAKE_MODULE_PATH:PATH=/opt/python/cp38-cp38/lib/python3.8/site-packages/skbuild/resources/cmake" "-DITK_DIR:PATH=/work/ITK-cp38-cp38-manylinux_2_28_x64" "-DITK_USE_SYSTEM_SWIG:BOOL=ON" "-DWRAP_ITK_INSTALL_COMPONENT_IDENTIFIER:STRING=PythonWheel" "-DSWIG_EXECUTABLE:FILEPATH=/work/ITK-cp38-cp38-manylinux_2_28_x64/Wrapping/Generators/SwigInterface/swig/bin/swig" "-DCMAKE_CXX_COMPILER_TARGET:STRING=x86_64-linux-gnu" "-DCMAKE_INSTALL_LIBDIR:STRING=lib" "-DBUILD_TESTING:BOOL=OFF" "-DPython3_EXECUTABLE:FILEPATH=/opt/python/cp38-cp38/bin/python" "-DPython3_INCLUDE_DIR:PATH=/opt/python/cp38-cp38/bin/../include/python3.8" "-DCMAKE_BUILD_TYPE:STRING=Release"

This might be a problem in https://github.com/python-cmake-buildsystem/python-cmake-buildsystem.

Hello I wanted to know if the itkpythonpackage provides bindings for the deformable registration components of itk. So far i havent found this using google search.

Thansk

Several quality-of-life fixes and updates for ARM support:

• Consolidates ARM module script with x86_64 module script for easier maintenance and comparison between procedures. Internal ARM script is preserved as a wrapper around generic internal build script.
• Splits MANYLINUX_VERSION variable into MANYLINUX_VERSION prefix and TARGET_ARCH postfix to better reflect available images.
• Uses sudo to avoid permissions failure when running docker or cleaning up files on ARM systems

Applies changes introduced by @thewtex in https://github.com/InsightSoftwareConsortium/ITKPythonPackage/pull/234.

Tests have passed at https://github.com/InsightSoftwareConsortium/ITKSplitComponents/actions/runs/3736106376/jobs/6340059855. Note that ARM builds on Github Actions runners are significantly slower than x86/x64 builds due to emulation. ITKSplitComponents Linux jobs previously completed in ~10 minutes and now complete in ~30 minutes with the addition of ARM wheels.

co-authored-by: Matt McCormick [email protected]

Error log:

CMake Error at Wrapping/CMakeUtilityFunctions.cmake:40 (math):
  math cannot parse the expression: ")

  set(ITK_WRAP_VECTOR_COMPONENTS + 1": syntax error, unexpected
  exp_CLOSEPARENT (1).
Call Stack (most recent call first):
  Wrapping/WrapBasicTypes.cmake:55 (INCREMENT)
  Wrapping/ConfigureWrapping.cmake:131 (include)
  Wrapping/CMakeLists.txt:97 (include)


CMake Warning (dev) at Wrapping/CMakeUtilityFunctions.cmake:40 (math):
  Unexpected character in expression at position 1: "

Call Stack (most recent call first):
  Wrapping/WrapBasicTypes.cmake:63 (INCREMENT)
  Wrapping/ConfigureWrapping.cmake:131 (include)
  Wrapping/CMakeLists.txt:97 (include)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Error at Wrapping/WrapBasicTypes.cmake:73 (message):
  ITK_WRAP_VECTOR_COMPONENTS must include ITK_WRAP_IMAGE_DIMS
Call Stack (most recent call first):
  Wrapping/ConfigureWrapping.cmake:131 (include)
  Wrapping/CMakeLists.txt:97 (include)

See the complete build log here