autoPatchelfHook only resolves DT_NEEDED entries, so a library reached
only through dlopen never lands in any RUNPATH -- listing its provider
in buildInputs contributes nothing. Several components dlopen by bare
soname and so silently lose those libraries at runtime.
Add the missing paths with appendRunpaths for the redists, and an
explicit postFixup for the two source builds, which do not go through
buildRedist:
- cudnn, libcublas, libcufft, libcusparse, libcusparse_lt: NVRTC and
nvJitLink, dlopen'd to compile kernels at runtime. libcublas gained
the dlopen in 12.8 and libcusparse_lt in 0.8, so both are
version-gated. libcusparse's libnvJitLink moved from DT_NEEDED to
dlopen at 12.7.3.1; the entry is left unconditional because it is a
no-op before that.
- libcufile: libudev, libmount, liburcu and libnuma.
- nccl, libnvshmem: libibverbs, libmlx5 and libgdrapi. NCCL builds
with RDMA_CORE=0 and MLX5DV=0, so none of these are DT_NEEDED;
without this NCCL logs at INFO and silently falls back to the socket
transport. Both also gain autoAddDriverRunpath, which nothing was
supplying -- libnccl dlopens libnvidia-ml.so.1, and the statically
linked CUDA runtime dlopens libcuda.so.1.
Also:
- cuda_cupti: ship the static archives as their own output on
linux-sbsa, where they were previously left in the propagated lib
output. Gate on hostRedistSystem, since linux-aarch64 ships no
archives at all and declaring an empty output fails the build.
- libcuobjclient: declare rdma-core, which had been resolved only by
accident through libcufile's runpath.
- libcusolver: note the vendored METIS in meta.license.
Verified across cudaPackages_12_6 through _13_3 on linux-x86_64 and
linux-sbsa, and on linux-aarch64 for the CUDA 12 releases where that
redist system exists. nccl is unavailable on linux-aarch64, since
pre-Thor Jetsons are unsupported upstream, so libnvshmem builds there
with withNccl disabled.
Known and deliberately left alone: appendRunpaths is applied to every
ELF in every output, so it also writes into stubs outputs, where the
entries are inert. Nothing in-tree consumes the affected stubs
outputs.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Build systems bake absolute paths into installed artifacts: nvcc
records its own location in the linker command lines it embeds, and
CMake freezes whatever it resolved at configure time into exported
targets. Nix counts any store hash as a reference, so a compiler that
is only ever a nativeBuildInput ends up a runtime dependency.
- gdrcopy: gdrcopy_pplat is the only test built with relocatable
device code, and nvlink embeds its command line, naming both
cuda_nvcc and the cudart that supplied cudadevrt. Neither is needed
at runtime: no binary here has libcudart in DT_NEEDED, and
libcuda.so.1 comes from the driver. CUDA 13 only; on 13.3 the
closure drops from 688,439,736 to 61,081,560 bytes, and all seven
releases now have identical reference sets.
- cudnn-frontend: upstream passes CUDAToolkit_INCLUDE_DIRS to
target_include_directories as a bare absolute path and never
forwards the dependency, so consumers inherit a build-machine path
instead of resolving the toolkit themselves. Confine the path to the
build and export the dependency, so find_package(CUDAToolkit) runs
in the consumer's environment. Closure drops from 1,360,621,552 to
171,758,136 bytes. This is load-bearing rather than cosmetic: on
CUDA 12 crt/ ships in cuda_nvcc and cuda_runtime_api.h includes it,
so a consumer using only find_package(cudnn_frontend) previously
relied on that exported path to compile at all.
- libnvshmem: NVSHMEMEnv.cmake bakes every -D*_HOME into
NVSHMEM_BUILD_VARS, a diagnostic banner that nvshmem-info and
init.cu only ever print, and substitutes it into an installed header
so consumers inherit it too. Strip the dev outputs and nvcc; gdrcopy
and mpi appear in the same string but are genuine runtime
dependencies. References drop from 16 to 12.
gdrcopy also gains a disallowedRequisites guard so the leak cannot
return unnoticed. libnvshmem deliberately does not: ucx and openmpi
pull nvcc into its closure independently of the banner, so the guard
would fail for reasons unrelated to this change.
Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
`withNccl` defaults to `true`, unconditionally adding `nccl` to `buildInputs`.
This is problematic on platforms where NCCL is unavailable, such as pre-Thor Jetson (Orin), where `nccl.meta.available` is `false` due to its `badPlatforms` assertion. In such cases, libnvshmem would still pull the unavailable `nccl` into its closure, leading to an eval-time error.
We are changing the default to `nccl.meta.available` to make libnvshmem skip NCCL automatically on platforms where NCCL is unsupported. We preserving the existing behaviour everywhere else (x86_64-linux, Thor Jetson) where `nccl.meta.available` is `true`.
Note that this guard has already been added to other CUDA modules such as `cudaPackages.cudss` in #437723.
See https://developer.nvidia.com/tensorrt/download/11x announcements
for details.
Format Filename pattern
Tar (10.x) TensorRT-<version>.<os>.<arch>-gnu.cuda-<cuda_version>.tar.gz
Tar (11.x) TensorRT-<product>-<product_version>-<os>-<arch>-cuda-<cuda_version>-Release-external.tar.zst
Zip (10.x) TensorRT-<version>.<os>.<arch>.cuda-<cudaver>.zip
Zip (11.x) TensorRT-<product>-<product_version>-<os>-<arch>-cuda-<cuda_version>-Release-external.zip
If the tar is a zstd-compressed, we need to add zstd to
nativeBuildInputs to unpack the source. TensorRT 11.0.0 has switched to
.tar.zst for their redistributables.
