cuda

C+ bindings for the CUDA runtime (cuda_runtime_api.h) and cuBLAS (cublas.h), generated by cpc-bindgen --cpackage (see Cplus.toml for the reproduce line). The modules are generated: never edit them; regenerate.

import "cuda/cuda_runtime_api" as cuda;

var count: i32 = 0;
let rc: i32 = cuda::cudaGetDeviceCount(#addr_of(count));

Linking

[link] search-paths is ${CUDA_LIB:-/usr/local/cuda/lib64}: set CUDA_LIB to the toolkit's library directory when it is anywhere else.

• Linux: /usr/local/cuda/lib64 by default. The directory is also baked into the binary as an rpath, so no LD_LIBRARY_PATH is needed.
• Windows: CUDA_LIB=%CUDA_PATH%\lib\x64 (for example D:\libraries\cuda-12.6\lib\x64). A PE image has no rpath: cudart64_*.dll and cublas64_*.dll are found at run time on PATH (the CUDA installer puts %CUDA_PATH%\bin there) or beside the executable.

Windows modules

src/*_windows.cplus shadow the shared modules on Windows (the resolver's platform override). The shared ones come from the Linux headers and bind entry points Windows' cudart.lib does not export - cudaDeviceGetNvSciSyncAttributes (NvSciSync is Linux/QNX only) - so a Windows program importing them did not link. The Windows modules are generated from the Windows toolkit's headers with that symbol skipped:

cpc-bindgen --cpackage --out vendor/cuda --variant windows \
  --header %CUDA_PATH%/include/cuda_runtime_api.h --header %CUDA_PATH%/include/cublas.h \
  --clib cudart --clib cublas --skip cudaDeviceGetNvSciSyncAttributes -- -I %CUDA_PATH%/include

(generated from CUDA 12.6). Add a --skip for any other symbol a Windows link reports undefined.

cpc test here links the runtime and counts devices (src/test_main.cplus). It does not prove the Windows modules are complete: a test build compiles away wrappers nothing calls, so an unexported symbol only fails an APPLICATION build that imports the module - build one after regenerating.