[Debian-pan-maintainers] Bug#1023347: tomopy: CUDA + MKL => FTBFS

[Andreas Beckmann]

Source: tomopy
Version: 1.10.4+ds1-4
Severity: important
Tags: ftbfs

Hi,

MKL detection currently does not work. I have a fix for that (pushed to
branch mkl-detection), but it causes an FTBFS on amd64 when nvcc
attempts to link against both libdl.a and -ldl. Unfortunately that does
not seem to be reproducible on salsa ci, cuda detection does not seem
to work there.
I'll try to debug the cuda detection issue on salsa, but no promises.

...
[41/44] Building CUDA object source/libtomo/accel/CMakeFiles/libtomopy-accel.dir/gpu/sirt.cu.o
nvcc warning : The 'compute_35', 'compute_37', 'sm_35', and 'sm_37' architectures are deprecated, and may be removed in a future release (Use -Wno-deprecated-gpu-targets to suppress warning).
[42/44] Linking CXX shared library CMakeFiles/libtomopy-accel.dir/cmake_device_link.o
FAILED: CMakeFiles/libtomopy-accel.dir/cmake_device_link.o
/usr/bin/nvcc -forward-unknown-to-host-compiler -ccbin=cuda-g++ -O3 -DNDEBUG  -Xcompiler=-fPIC -Wno-deprecated-gpu-targets -shared -dlink source/libtomo/accel/CMakeFiles/libtomopy-accel.dir/cxx/common.cc.o source/libtomo/accel/CMakeFiles/libtomopy-accel.dir/cxx/mlem.cc.o source/libtomo/accel/CMakeFiles/libtomopy-accel.dir/cxx/sirt.cc.o source/libtomo/accel/CMakeFiles/libtomopy-accel.dir/gpu/common.cu.o source/libtomo/accel/CMakeFiles/libtomopy-accel.dir/gpu/mlem.cu.o source/libtomo/accel/CMakeFiles/libtomopy-accel.dir/gpu/sirt.cu.o source/libtomo/accel/CMakeFiles/libtomopy-accel.dir/gpu/utils.cu.o -o CMakeFiles/libtomopy-accel.dir/cmake_device_link.o -L/usr/lib/x86_64-linux-gnu/stubs  -L/usr/lib/gcc/x86_64-linux-gnu/11 -lm /usr/lib/x86_64-linux-gnu/libdl.a libptl.a /usr/lib/x86_64-linux-gnu/libnpps_static.a /usr/lib/x86_64-linux-gnu/libnppig_static.a /usr/lib/x86_64-linux-gnu/libnppisu_static.a /usr/lib/x86_64-linux-gnu/libnppc_static.a /usr/lib/x86_64-linux-gnu/libculibos.a -lcudadevrt -lcudart_static -lrt -lpthread -ldl
nvlink warning : Skipping incompatible '/usr/lib/x86_64-linux-gnu/librt.a' when searching for -lrt
nvlink warning : Skipping incompatible '/usr/lib/x86_64-linux-gnu/libpthread.a' when searching for -lpthread
nvlink warning : Skipping incompatible '/usr/lib/x86_64-linux-gnu/libdl.a' when searching for -ldl
nvlink fatal   : Could not open input file '/usr/lib/x86_64-linux-gnu/libdl.a'
ninja: build stopped: subcommand failed.
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/skbuild/setuptools_wrap.py", line 645, in setup
    cmkr.make(make_args, install_target=cmake_install_target, env=env)
  File "/usr/lib/python3/dist-packages/skbuild/cmaker.py", line 680, in make
    self.make_impl(clargs=clargs, config=config, source_dir=source_dir, install_target=install_target, env=env)
  File "/usr/lib/python3/dist-packages/skbuild/cmaker.py", line 704, in make_impl
    raise SKBuildError(

An error occurred while building with CMake.
  Command:
    cmake --build . --target install --config Release --
  Install target:
    install
  Source directory:
    /build/tomopy-1.10.4+ds1
  Working directory:
    /build/tomopy-1.10.4+ds1/_skbuild/linux-x86_64-3.10/cmake-build
Please check the install target is valid and see CMake's output for more information.
E: pybuild pybuild:379: build: plugin distutils failed with: exit code=1: /usr/bin/python3 setup.py build
dh_auto_build: error: pybuild --build -i python{version} -p 3.10 returned exit code 13
make: *** [debian/rules:6: build-arch] Error 13
...

The package uses some kind of non-verbose build that is a) not disabled
by the default measures to get a verbose build and b) not detected by
blhc. That makes debugging more difficult than neccessary.
https://salsa.debian.org/python-team/packages/tomopy/-/jobs/3463730#L3849

There are so many nested build systems involved ... I have no idea where
the bad linking command originates from.


Andreas