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>
