[SyneRBI/SIRF-SuperBuild] CI: docker tests fail because Gadgetron is not running (Issue #991)
Edoardo Pasca
paskino created an issue (SyneRBI/SIRF-SuperBuild#991)On the docker CI there is a unittest error due to Gadgetron not running:
https://github.com/SyneRBI/SIRF-SuperBuild/actions/runs/23753206678/job/69336589226?pr=989
Thread from Discord.
The error is explained by @wjp and solution is also given:
It's definitely an interesting situation. I think I worked it out. If I read the build log correctly, weird things are happening with the HDF5 libraries. Specifically it seems it can't find libhdf5.so.320 when loading gadgetron.
From what I can tell, the gadgetron binary isn't linked against libhdf5.so.320 directly (only indirectly), so its RUNPATH isn't taking effect for that particular shared object. It's libismrmrd.so that has the direct libhdf5.so.320 dependency, but libismrmrd doesn't have RUNPATH set.
In the previous branch, this wasn't a problem since it was picking up hdf5 from somewhere behind /usr (which is in the system search path), but in this branch it's picking up hdf5 from /opt/conda. (Which in turn seems to be caused by it installing hdf5-2.1 from conda-forge now instead of the older hdf5-1.14. I haven't dug into FindHDF5.cmake to see why that matters).
Arguably the cleanest way to fix this would be to add set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE) to ISMRMRD's CMakeLists.txt to give libismrmrd.so the right RUNPATH. (An easier approach might be to add /opt/conda/lib to LD_LIBRARY_PATH, but I find it hard to judge if that will have unexpected consequences.)
I've tried the runpath approach, and this updated ismrmrd patch seems to fix things for me: https://github.com/wjp/SIRF-SuperBuild/tree/paskino_fix-sirf-cil-unittests (Specifically 9978261 )
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.