Does `cucim` need to link against the CUDA driver?

[gforsyth]

While working on stable install testing (xref rapidsai/build-planning#227), I noticed that cucim imports were throwing an error on all CUDA and Python versions we were testing:

>>> import cucim
dlopen error libcuda.so.1: cannot open shared object file: No such file or directory
 missing cuda symbols while dynamic loading
 cuFile initialization failed

After meeting with the team, we identified that libcuda.so.1 isn't available when running in a non-GPU-enabled docker container (in this case rapidsai/citestwheel running without --gpus).

After adding --gpus all to the container instantiation, everything imports and runs without issue.

So, everything is working as expected, which is great! The question is whether or not cucim needs to link against the driver. If it doesn't, it means we can perform simple symbol loading tests on a CPU-only runner. That's not a huge priority, but it is a nice-to-have if the current driver linking isn't necessary.

In the short term, I'm going to ignore that particular error from cucim imports in rapidsai/integration#837

Medium-term, we plan to improve the depth of import and general usage tests which will require GPU runners anyway

[jakirkham]

Thanks Gil! 🙏

Could you please share how cucim was installed as well as the container used (and how it was run)?

[gforsyth]

For CPU-only, where the dlopen error appears, I used (among others):

docker run -it rapidsai/citestwheel:26.04-cuda13.0.2-ubuntu22.04-py3.11-amd64 /bin/bash

Then inside the container, using the default env, I ran:

pip install cucim-cu13 --extra-index-url=https://pypi.nvidia.com --isolated

then

>>> import cucim
dlopen error libcuda.so.1: cannot open shared object file: No such file or directory
 missing cuda symbols while dynamic loading
 cuFile initialization failed

For GPU-enabled (where there is no error):

docker run -it --gpus all rapidsai/citestwheel:26.04-cuda13.0.2-ubuntu22.04-py3.11-amd64 /bin/bash

Then the same install command as above.