Starting in CUDA 12.9 the `nvToolsExt` library is no longer provided.
C and C++ projects should switch over to `nvtx3`.
Projects that previously used `nvToolsExt` with Fortran, can now use the
new `CUDA::nvtx3_interop` target for the same functionality with the new
NVTX v3 API.
Upcoming versions of nvcc are adding support for `SYSTEM_INCLUDES`
which contain includes that are implicitly used with `-isystem`
instead of `-I`.
Support of this is needed in CMake as some CUDA Toolkit releases will
start to have a different include directory layout and using only the
output from `INCLUDES` will be insufficient to find all headers.
Previously we relied on the cross-compiling toolchain file to set
`CMAKE_SYSTEM_PROCESSOR` to a value consistent with the CUDA compiler's
target architecture. When a compiled language is enabled, we now have
its target architecture in `CMAKE_<LANG>_COMPILER_ARCHITECTURE_ID`.
Use that to select the CUDA toolkit's corresponding target directory.
If no language is enabled, or the compiler's target architecture is not
known, fall back to `CMAKE_SYSTEM_PROCESSOR`. If that is not set, fail
with an explicit error make clear what is wrong.
In commit f69b9b7305 (CUDAToolkit: Restore ability to find cupti
headers, 2023-12-08, v3.28.1~8^2) we did not update the CUPTI library
searches to add the extra search path needed for certain install layouts
(only the header search path). Add the additional library search paths.
Fixes: #26770
Issue: #25484
Since commit 6636693134 (FindCUDAToolkit: Re-unify with
Internal/CUDAToolkit, 2020-06-11, v3.18.0-rc2~6^2~7) the table is
duplicated.
Update the CUDA target directory table for Clang to account for changes
to the equivalent table in FindCUDAToolkit:
* commit bcdd486bf7 (CUDA: Enable support on QNX, 2020-10-30,
v3.19.0-rc3~8^2~1)
* commit 743d4181b4 (FindCUDAToolkit: Support cross-compilation to
sbsa-linux, 2023-01-11, v3.26.0-rc1~118^2)
`FindThreads` requires that C or CXX be enabled. Previously we were
only checking that `CMAKE_{C,CXX}_COMPILER` have been set, which does
not mean the languages have been enabled.
Since commit d74210a8bd (CMP0017: Remove support for OLD behavior,
2024-11-17) we can rely on CMP0017's NEW behavior unconditionally.
Calling `include(FindPackageHandleStandardArgs)` in a builtin module
will always get the builtin `FindPackageHandleStandardArgs`.
The dependency on nvJitLink was due to misunderstanding how runtime compiled code that uses
LTO is used. It doesn't require nvrtc to have a dependency on nvJitLink, just the caller.
Depending on nvrtc-builtins breaks CUDA enhanced compatibility across
minor versions. The static version of nvrtc continues to need the
dependency due to undefined symbols
The nvrtc-builtins and nvptxcompiler projects don't required linking
to the cuda driver. We previously did this due to reading the
upstream documentation incorrectly.
We represent stub libraries, e.g., for CUDA, using imported `SHARED`
library targets with only `IMPORTED_IMPLIB`, and no `IMPORTED_LOCATION`,
to indicate that the stub file is meant only for linkers and not dynamic
loaders. See commit 7351d590ee (cmTarget: Add a way to represent
imported shared library stubs, 2023-07-17, v3.28.0-rc1~344^2) and commit
fc6508921c (cmComputeLinkInformation: Restore soname lookup for
non-imported targets, 2023-12-05, v3.28.0~4^2).
If a shared library is linked to a stub, it has a `NEEDED` field
populated with the `SONAME` found in the stub. When a dependent target
links to such a shared library, some linkers want to find a library file
on disk and load it to see what symbols it provides. This is necessary
for linkers that enforce `--no-allow-shlib-undefined`. On hosts with
only the stub library installed, e.g., with only the CUDA toolkit
development package, the real runtime library corresponding to the
stub's `SONAME` may not even exist, so no `-rpath-link` flag can help
linkers find it. Pass the stub library to linkers explicitly so they
can find it without searching.
Fixes#25484
PR !8835 failed to update the CUPTI header searches to use the
new internal FindCUDAToolkit search variables. This caused the
CUDA::cupti target to always not exist.
Since commit 0744c02e24 (FindCUDAToolkit: targets pointing to stubs now
use IMPORTED_IMPLIB, 2023-07-24, v3.28.0-rc1~309^2) we recognize CUDA
stub libraries and represent them in a special way. However, the logic
only works on the first configuration of a build tree when the libraries
are first found. Once the results are cached, we incorrectly revert to
the non-stub representation.
Fix this by recognizing stub libraries based on their path instead.
Improves the handling of CUDA layouts where we have multiple include
and library directories listed in the output of `nvcc -v`. This
updates both when the CUDA language is enabled or not.
Fixes: #24915
Previously REAL_PATH would collapse paths before resolving any symlinks
so if `..` crossed a symlink the output from `REAL_PATH` would be wrong.
It looked like REAL_PATH did this by mistake since it was a side-effect
of ensuring we had an absolute path before resolving symlinks.
The lib is named `libnvrtc-builtins.so`, not `libnvrtc_builtins.so`.
Update the change from commit 2a94c762ed (FindCUDAToolkit: Add support
for CUDA::nvrtc_static, 2023-01-20, v3.26.0-rc1~55^2). Apply a fix
similar to commit 9688a8ebc2 (FindCUDAToolkit: Fix
`nvrtc_builtins_static` library name, 2023-02-03, v3.26.0-rc2~15^2).
