Hi, installing CUDA on a Ubuntu or Debian machine from contrib/non-free/multiverse will lead to a "scattered" CUDA a bit different from what the Nvidia installer creates. For Debian 8.0 "Jessie", the provided "contrib" CUDA 6.0 looks like this: /usr/bin/nvcc /usr/include/cuda.h /usr/lib/x86_64-linux-gnu/libcuda.so /usr/lib/x86_64-linux-gnu/libcudart.so [...] Details: https://packages.debian.org/jessie/amd64/nvidia-cuda-dev/filelist https://packages.debian.org/jessie/amd64/nvidia-cuda-toolkit/filelist Trying to compile a .cu file with clang++ --cuda-path=/usr does not get recognised as a valid install. It would be great if such install paths would be supported, too. (Created on request, see http://lists.llvm.org/pipermail/cfe-dev/2016-March/047994.html)
This would be great to support.
CUDA 6.0 is quite a few releases out of date and is probably not going to be supported. As for detection of CUDA installation integrated with host headers/libraries, it should be doable.
There is 6.5 in Debian stable backports: https://tracker.debian.org/pkg/nvidia-cuda-toolkit Anyhow, split CUDA support would be useful.
Yes, it's also not so much about the fact that it is an old version of CUDA (which it will always be in Debian). The report is about the system-specific install path that will probably stay this way with 6.5, 7.0, 7.5, ...
Hi, the problem is still an issue and quite a problem for distributed CUDA and Clang versions. I reported the issue also in Ubuntu in https://bugs.launchpad.net/ubuntu/+source/clang/+bug/1706326 and cross-linked here. Is it possible to make the CUDA install detection in clang a bit more flexible, e.g. by allowing to provide a --cuda-include-path --cuda-library-path prefix? The --cuda-path option used today could then just set both to the same value as a convenience switch. What are the exact components that need to be fund by clang? Only the cuda headers and libcuda.so + libcudart.so?
@Axel It's possible to add all those flags, but I'm not sure it's worth it. If/when clang needs to use something else from the CUDA SDK, we'll need another flag and that would break all current users. IMO, it would be easier/better to re-create original CUDA directory structure in one place using symlinks to point to the bits and pieces of CUDA SDK as installed on your system. This way compiler can rely on the same directory structure everywhere and the packaging/installation of CUDA on particular system can do whatever it wants. E.g: /usr/local/cuda-8.0 -> /usr/share/cuda-8.0-shim /usr/share/cuda-8.0-shim: lib64 -> /usr/lib64 includes -> /usr/include (or just symlink CUDA headers) bin -> /usr/bin nvvm/libdevice -> wherever/libdevice/is version.txt -> wherever/is/the/real/version.txt (or just echo 8.0.0 into it)
Looks like such a shim package is coming for Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882505
Yes, I reported this upstream as well: https://bugs.launchpad.net/ubuntu/+source/nvidia-cuda-toolkit/+bug/1706326