Anaconda LibITK 5.3.0 MacOS ARM64 packaging failures

1

We are trying to package our own library (GitHub - BlueQuartzSoftware/complex: The backend algorithms and framework associated with DREAM3DNX, a data analysis program for materials science data analytics) into an anaconda package. Our library has a dependency on ITK 5. Currently we use ITK 5.2.1 which seems to work fine on both macOS x86_64 and macOS ARM64. We recently have been trying to update to ITK 5.3.0 (After removing some troublesome C++ code on our side that massages a bug in the ITK 5.3.0 headers) and while everything compiles just fine on both systems, the anaconda testing fails on the ARM64 side of things.

It is reproducible on my system simply by setting the requirement from ITK 5.2.1 to ITK 5.3.0 (using both libITK and libitk-devel).

Has anyone else seen this kind of behavior? Anyone is welcome to give it a try. There is a “conda” directory in the top level of the “complex” repo.

cd complex/conda
conda create --name cx-build python=3.10 
conda activate cx-build
conda install conda-build
conda build .

The just change the meta.yaml file to use ITK 5.3.0 instead of ITK 5.2.1 and the final testing phase of the packaging will fail.

Anyone have any thoughts?

What is the procedure to attempt to test the ITK 5.4.0 RCs?

Intel System is running Xcode 14.2 and the ARM system is running Xcode 13.3

2

It has been a while since I tried to build with conda on OSX. I think is was only with x86-64 architectures.

When I did I was not able to successfully compile and run the results due to XCode/OSX libraries not matching between distributed packages and what was compiled locally.

3

I’m going to give it another try after updating to the a newer Xcode on the ARM/Monterey machine.

What is the confidence level that ITK 5.4.0 will solve any ARM64 issues on macOS?

I’m trying to figure out how to start pulling the RC, build an anaconda package for ITK, then use that ITK inside our own built anaconda package. I guess I could build the ITK 5.4 anaconda package and upload to our own channel for testing. Although I thought I read something ITK builds PyPi wheels first, then just repackages those into an Anaconda package? Maybe the tooling is just different enough between how Pypi does it and how Anaconda does it?

4

This is the “libitk” feedstock for condo-forge:

This is different that the “itk” condo-forge feed stock which is just for python and does the PyPI packaging.

The “libitk” feedstock is used by “libsimpleitk” and the “simpleitk” feed stocks with the latter being a python distribution based on the others and the full condo-forge packages. You may want to look through those feed stocks to see how it all works. It took a while to get it all working and has had continual improvements and changes over the years.

5

Thank you for the links. Does this also generate the libitk-devel conda package?

6

Yes.

7

Now I am thinking about just directly compiling ITK as part of our build script but using “ITK_CUSTOM_LIBRARY_SUFFIX” and set that to something that will not interfere with an ITK that would be installed by Anaconda. I have done with a few other libraries to get around the versioning issues that we are having.

Is there a ITK_CUSTOM_LIBRARY_PREFIX variable? I don’t have access to the ITK code at the moment to search.

8

If the condo-forge build an infrastructure is useful, we could looking supporting prerelease build in the feed stock. What that be useful?

9

I think it might be useful to at least be able to report back any issues that we would have before the official 5.4.0 version was released.

Is there a ITK_CUSTOM_LIBRARY_PREFIX variable? I don’t have access to the ITK code at the moment to search.