jdenny added a comment. Herald added a project: LLVM. In D55269#1320382 <https://reviews.llvm.org/D55269#1320382>, @tra wrote:
> In D55269#1320207 <https://reviews.llvm.org/D55269#1320207>, @Hahnfeld wrote: > > > In D55269#1319109 <https://reviews.llvm.org/D55269#1319109>, @jdenny wrote: > > > > > [...] > > > > > > In D55269#1318901 <https://reviews.llvm.org/D55269#1318901>, @tra wrote: > > > > > > > --cuda-path=/usr was never supposed to work -- /usr is *not* the root > > > > of the CUDA SDK. > > > > > > > > > /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). Is it fair then to say that /usr/lib/cuda isn't > > > the root either? > > > > > > [...] > > > > > > It seems that nvidia-cuda-toolkit still isn't installing a complete CUDA > > > install in one location. 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. > > > > > > I think this needs to be fixed then: The shim package should provide links > > to all necessary things and CMake must be prepared to deal with it. IMO we > > shouldn't workaround broken build system detection in the compiler. > > > That's exactly what I proposed to Debian folks > https://bugs.llvm.org/show_bug.cgi?id=26966#c6 and I was under impression > that that's what they did. It appears that they only created an empty > directory structure with version.txt in it. At least that's what I see when I > unpack nvidia-cuda-toolkit_9.1.85-3ubuntu1_amd64.deb. Perhaps they do > something extra in the install script, but I didn't find anything obvious in > the deb itself. > > > > > > > In D55269#1319116 <https://reviews.llvm.org/D55269#1319116>, @jdenny wrote: > > > >> By the way, nvidia-cuda-toolkit does install the following, but there's no > >> nvvm directory as clang currently expects: > > > > > > Then again the distro's packaging is broken and needs to be adjusted. > > Perhaps we can build a shim package ourselves and distribute it along with > the clang. This would decouple usability of clang from the Ubuntu/Debian > release process and would make it possible to make clang work with CUDA on > older debian/Ubuntu versions. > > >> Let's start with fixing OpenMP's cmake files. Once it no longer insists on > >> specifying --cuda-path=/usr, and isUbuntu is in place, what is the > >> remaining failure that you see? > > > > I disagree here: It's not OpenMP but CMake that's detecting the wrong path > > here. This is the place to fix it once and for all (and possibly get the > > shim package right in that process). > > It's somewhat orthogonal, IMO. I agree that it's not OpenMP's problem. Cmake > will fix it at some point in future, but, presumably, we want OpenMP > buildable *now*. Adding a temporary workaround for something that Cmake can't > handle now would make building OpenMP with clang somewhat easier which was > the end goal of this patch. In the end it's up to OpenMP maintainers what > they would want to do. For openmp, I worked around the aforementioned cmake limitation in D55588 <https://reviews.llvm.org/D55588>. I reported the aforementioned problem with the Ubuntu package nvidia-cuda-toolkit in December at: https://bugs.launchpad.net/ubuntu/+source/nvidia-cuda-toolkit/+bug/1808999 Today, I received a response (included at the above link) that this is not a valid bug and that clang++ works fine with nvidia-cuda-toolkit. I suppose the latter half is true, but the point is that we're having to work around the strange Debian/Ubuntu packaging in both Clang and our cmake files. Do people here think it's worth pursuing this point further with Debian/Ubuntu package maintainers? Repository: rL LLVM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D55269/new/ https://reviews.llvm.org/D55269 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
