[PATCH] D55269: [CUDA] Fix nvidia-cuda-toolkit detection on Ubuntu

[Joel E. Denny via Phabricator via cfe-commits]

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