Build the CUDA buffer backend against CUDA 13 - #7
Open
ayusmans wants to merge 1 commit into
Open
Conversation
The published ros-lyrical-cuda-buffer{,-backend} 0.1.2 debs depend on
libcudart12 and nvidia-cuda-toolkit, i.e. Ubuntu Noble's distro CUDA
toolkit, which is 12.x. Consumers such as the Isaac ROS workspace build
against CUDA 13.2, so loading the backend brings a second CUDA runtime
into the process.
The toolkit was selected by a workaround that pre-seeded
CUDAToolkit_INCLUDE_DIRECTORIES from a find_path hinting /usr/include,
matching Ubuntu's split nvidia-cuda-dev layout. That only set include
directories, so headers and the CUDA:: imported libraries could come
from different toolkits with no error. Drop it: the NVIDIA cuda-toolkit-13
packages install a complete toolkit under /usr/local/cuda-13.x, which
FindCUDAToolkit locates on its own, since it puts /usr/local/cuda at the
front of its search paths.
Depend on the nvidia-cuda-13 rosdep key so the build environment gets
that toolkit, and require CUDA 13 in CMake so a fallback to 12.x fails
the build rather than silently producing a mismatched library.
FindCUDAToolkit treats a requested version as a minimum and does not opt
into CMake's version-range handling, so the upper bound is a separate
check; without it CUDA 14 would satisfy find_package(CUDAToolkit 13).
cuda_buffer_backend gets the same treatment: it links CUDA::cudart and
CUDA::cuda_driver itself, and its deb has the same libcudart12
dependency, so constraining cuda_buffer alone would not have been enough.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The published ros-lyrical-cuda-buffer{,-backend} 0.1.2 debs depend on libcudart12 and nvidia-cuda-toolkit, i.e. Ubuntu Noble's distro CUDA toolkit, which is 12.x. Consumers such as the Isaac ROS workspace build against CUDA 13.2, so loading the backend brings a second CUDA runtime into the process.
The toolkit was selected by a workaround that pre-seeded CUDAToolkit_INCLUDE_DIRECTORIES from a find_path hinting /usr/include, matching Ubuntu's split nvidia-cuda-dev layout. That only set include directories, so headers and the CUDA:: imported libraries could come from different toolkits with no error. Drop it: the NVIDIA cuda-toolkit-13 packages install a complete toolkit under /usr/local/cuda-13.x, which FindCUDAToolkit locates on its own, since it puts /usr/local/cuda at the front of its search paths.
Depend on the nvidia-cuda-13 rosdep key so the build environment gets that toolkit, and require CUDA 13 in CMake so a fallback to 12.x fails the build rather than silently producing a mismatched library. FindCUDAToolkit treats a requested version as a minimum and does not opt into CMake's version-range handling, so the upper bound is a separate check; without it CUDA 14 would satisfy find_package(CUDAToolkit 13).
cuda_buffer_backend gets the same treatment: it links CUDA::cudart and CUDA::cuda_driver itself, and its deb has the same libcudart12 dependency, so constraining cuda_buffer alone would not have been enough.
Description
Fixes # (issue)
Is this user-facing behavior change?
Did you use Generative AI?
Additional Information