Page MenuHomePhabricator

[macOS] Resolve crashing executables after ITK v5.3 upgrade
Closed, ResolvedPublic

Description

mitkImageStatisticsHotspotTest
Error: /home/ubuntu/jenkins-agent/MITK/Continuous/build/ep/include/ITK-5.3/itkRealToHalfHermitianForwardFFTImageFilter.h:85:
ITK ERROR: Object factory failed to instantiate N3itk40RealToHalfHermitianForwardFFTImageFilterINS_5ImageIdLj3EEENS1_ISt7complexIdELj3EEEEE
Exception occurred during test execution: /home/ubuntu/jenkins-agent/MITK/Continuous/build/ep/include/ITK-5.3/itkRealToHalfHermitianForwardFFTImageFilter.h:85:
ITK ERROR: Object factory failed to instantiate N3itk40RealToHalfHermitianForwardFFTImageFilterINS_5ImageIdLj3EEENS1_ISt7complexIdELj3EEEEE [FAILED]
  +--> in /home/ubuntu/jenkins-agent/MITK/Continuous/src/MITK/Modules/ImageStatistics/Testing/mitkImageStatisticsHotspotTest.cpp, line 641, expression is false: "false"

Additionally, on macOS all tests fail because of:

dyld: Library not loaded: lib/libitkzlib-5.3.1.dylib
  Referenced from: /Users/jenkins/jenkins-agent/MITK/Continuous/build/MITK-build/lib/libMitkCore.dylib
  Reason: image not found

Event Timeline

kislinsk created this task.

Deleted branch from rMITK MITK: bugfix/T29636-FixITKv5.3FailingTests.

The mitkImageStatisticsHotspotTest should be fixed now. The reason was the backend of a FFT convolution filter that was not loaded, resp. the corresponding ITK object factory wasn't registered.

Still need to investigate the macOS shenanigans.

I just noticed that it tries to load lib/libitkzlib-5.3.1.dylib, where as the version should be v5.3 instead of v5.3.1. The ITK version upgrade was done from v5.2.1 to v5.3. I wonder if the .1 patch version has been carried over somehow and it can be fixed with a clean build? Let's see what the nightly clients will do tonight.

kislinsk renamed this task from Resolve failing tests after ITK v5.3 upgrade to [macOS] Resolve crashing executables after ITK v5.3 upgrade.Jun 20 2023, 9:08 AM
kislinsk raised the priority of this task from High to Unbreak Now!.

Okay I don't really understand where the .1 comes from but it is not relevant. The issue is that the reference to libitkzlib does not use rpath like all the other dependencies:

otool -L libMitkCore.dylib
...
@rpath/libitksys-5.3.1.dylib <- okay
lib/libitkzlib-5.3.1.dylib <- NOT okay
...

I figured out how to resolve it but before forking again, let's see what the upstream is doing with this information.
https://github.com/InsightSoftwareConsortium/ITK/issues/4084

Deleted branch from rMITK MITK: bugfix/T29636-fix-itkzlib-rpath.