- #UBUNTU NVIDIA CUDA TOOLKIT HOW TO#
- #UBUNTU NVIDIA CUDA TOOLKIT INSTALL#
- #UBUNTU NVIDIA CUDA TOOLKIT DOWNLOAD#
Openmp/libomptarget/cmake/Modules/LibomptargetNVPTXBitcodeLibrary.cmake is the file, and there's one occurrence of -cuda-path. I'm fairly certain I would see no remaining failure then, but it's not clear to me how we should convince OpenMP's cmake files to stop doing that. Once it no longer insists on specifying -cuda-path=/usr, and isUbuntu is in place, what is the remaining failure that you see? Let's start with fixing OpenMP's cmake files.
Granted, closer examination of the shim they've added shows that the shim is incomplete, but it's the right way to solve this problem, IMO. D40453 was my hint that people already agreed that's a worthwhile pursuit.Īnd I believe that we did convince Debian that it's up to them to arrange their packages in a way that works with clang.
#UBUNTU NVIDIA CUDA TOOLKIT INSTALL#
Whatever detects CUDA install path apparently does not do it correctly on Ubuntu (it's the same problem of having CUDA SDK bits all over the place) and that's something that needs to be fixed there.Īn easier workaround is to specify CUDA_TOOLKIT_ROOT_DIR when building llvm,īut my goal is make building on Ubuntu work without special configuration. If they want Clang compilation work with their variant of CUDA installation, they can always create a shim the way Debian did.Īs for cmake, it currently does not support clang as the CUDA compiler. Clang expects to see a monolithic CUDA SDK installation, specified, if necessary, with one option.ĭealing with distro-specific way SUDA SDK may be split there is up to the distro maintainers. I personally prefer to keep things as simple as possible. I don't think the added complexity is worth the effort. Once you have that flexibility, it will open a lot of possibilities to specify one of the options incorrectly and fail in some new and exciting way that nobody has seen before. If you want to solve the issue in general you need to be able to tell where to find each component of CUDA SDK needed by clang. It does not address the issue in principle - if we add tweaks do deal with Ubuntu oddities, why shouldn't we also add tweaks for any other linux distro?
#UBUNTU NVIDIA CUDA TOOLKIT HOW TO#
But just adding IsUbuntu() is not a full solution, so I'm looking for advice on how to proceed. I'm not adamant that handling -cuda-path=/usr is the right solution. D40453 was my hint that people already agreed that's a worthwhile pursuit. This will work on any linux distribution.Īn easier workaround is to specify CUDA_TOOLKIT_ROOT_DIR when building llvm, but my goal is make building on Ubuntu work without special configuration.
#UBUNTU NVIDIA CUDA TOOLKIT DOWNLOAD#
Just download CUDA SDK, install it into a local directory and point your build system there. I'm just trying to make it easy to build clang and openmp and call clang on the command line under Ubuntu. The cmake files I'm referring to are clang's.
I don't have a separate project using cmake. I do not think that changing clang to work around an issue in cmake files of one project is something we want to do. It sounds like you need to change your build system and tell clang the correct path. The fact that you want to add /usr/cuda/lib in this case suggests that /usr is the wrong path and /usr/lib/cuda is the correct one. In the end only one of those paths will be in effect and that's the path that should be specified via -cuda-path. It's odd apparently because nvidia-cuda-toolkit is odd. Treating -cuda-path=/usr as a special case was just a way to get there. My real goal is to get clang and openmp working out of the box on Ubuntu. It appears that what you're trying to do is to add "/usr/lib/cuda" on Ubuntu and Debian when -cuda-path=/usr is specified. Even if it installed it all to /usr/lib/cuda, FindCUDA.cmake would probably still see /usr/bin/nvcc and assume /usr is the CUDA install root. It seems that nvidia-cuda-toolkit still isn't installing a complete CUDA install in one location. I guess that just adding the check for isUbuntu() should make clang work on Ubuntu 18.04+. Is it fair then to say that /usr/lib/cuda isn't the root either? usr/lib/cuda/bin/nvcc doesn't exist, so that's probably why FindCUDA.cmake finds /usr/bin/nvcc (also installed by nvidia-cuda-toolkit). cuda-path=/usr was never supposed to work - /usr is *not* the root of the CUDA SDK. To be clear, I'm trying to address the use case where cmake/clang finds the cuda installation automatically. With that fix in place -cuda-path=/usr/lib/cuda should work. That change seems to be in Ubuntu bionic (18.04) Īpt confirms that's what I have: nvidia-cuda-toolkit 9.1.85-3ubuntu1 IIUIC, Debian has added a shim that pretends to be a monolithic CUDA install: I'm not sure that's something that needs to be fixed in clang.
0 kommentar(er)
