tambre added a comment. In D108247#3025238 <https://reviews.llvm.org/D108247#3025238>, @tra wrote:
> So, what's the current state of affairs regarding CUDA SDK layout in debian? `/usr/bin`: most executables <https://packages.debian.org/bullseye/amd64/nvidia-cuda-toolkit/filelist>, `nvcc` and `nvprof` shims `/usr/lib/nvidia-cuda-toolkit/bin`: `cicc`, `crt`, `nvcc`, `nvprof`, `g++` and `gcc` wrappers for supporting different compilers `/usr/lib/nvidia-cuda-toolkit/libdevice`: `libdevice.10.bc` `/usr/lib/cuda/{bin,include,lib64}`: empty directories `/usr/lib/cuda/nvvm/libdevice`: symlinked to `/usr/lib/nvidia-cuda-toolkit/libdevice` `/usr/include`: headers > CUDA SDK no longer ships version.txt, so cuda.h is the only reliable > mechanism for detecting CUDA version and clang does need to know it. > In case the version has not been found we also can not choose an arbitrary > old version as the default. Agreed, sensible. > So, one workaround would be to install CUDA-11.4. AFAICT, we do find the > headers and ptxas, but misdetect CUDA version. I don't think that's going to be acceptable for most distributions, which might ship a Clang supporting a newer CUDA than the one they ship. > Another workaround would be to place a fake /usr/lib/cuda/include/cuda.h with > something like this: My CMake CI bot [[ https://open.cdash.org/test/498767666 | encountered `cmath` template errors ]] after I manually symlinked `/usr/lib/cuda/include` to `/usr/include`, though that solved the version detection. Adding a shim like the one you show fixes everything and compiling works. > Clang does rely on very particular ordering of includes, so having CUDA > headers in a location clang does not expect will lead to issues sooner or > later. Having the headers in the system-wide `/usr/include` shouldn't be a problem though, right? I'm not quite sure why simply having `/usr/lib/cuda/include` → `/usr/include` symlink breaks as seen on my bot. Prior to this an empty `/usr/lib/cuda/include` and Clang finding them through the regular include search path worked. > If the headers are not available where --cuda-path points clang to, I'm not > sure what clang is supposed to do. Second-guessing explicit user input is not > a good idea in general. I agree that second-guessing is bad, but expecting it to be available in the include search path otherwise seems reasonable. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D108247/new/ https://reviews.llvm.org/D108247 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
