| 16 Oct 2025 |
 connor (he/him) | Plus, some of these binaries aren’t stand-alone — NVCC for example requires a host compiler.
So if we wanted to support arbitrary CUDA versions, we’d need to somehow know ahead of time which host compilers and versions are supported by all NVCC releases (we have a list we maintain in tree but it’s updated manually by reading release notes).
And then we’d need to use the appropriate version of the host compiler… but what if it’s not packaged in Nixpkgs? CUDA 11 releases used GCC 9, 10, and 11 and those aren’t maintained in-tree any more. | 14:14:59 |
| connor (he/him) | I’ve been working on the ability to extend the CUDA package set and make new ones for out of tree users, but it’s generally non-trivial and requires a great deal of familiarity | 14:17:53 |
| 17 Oct 2025 |
| connor (he/him) | The CUDA 13 PR now has libnvshmem, built from source (that was not fun)
It does not have nvshmem4py since that’s gonna be irritating to build and requires stuff we don’t have packaged yet | 01:16:43 |
| connor (he/him) | Lost about an hour of my life to figuring out that while they “support CMake” they don’t really support CMake
They do a full configure and build of a CMake project during a different project’s build and don’t thread arguments through properly, so there’s a fun note like this: https://github.com/NixOS/nixpkgs/blob/a32200680f4a5511fbc9456ff0fa689a0af12dac/pkgs/development/cuda-modules/packages/libnvshmem.nix#L104 | 01:19:55 |
| connor (he/him) | As part of this I also packaged gdrcopy (but not the driver bit, since I’m not sure what the best way to handle that is) | 01:21:18 |
| connor (he/him) | Gaétan Lepagedo you know if the PyTorch bump wants the nvshmem library or the Python bindings? | 01:40:29 |
 Gaétan Lepage | Thanks a lot for your work connor (he/him) (UTC-7)!!!
The PyTorch bump needs the library, not the python bindings. | 08:02:56 |
| 18 Oct 2025 |
|  @ihar.hrachyshka:matrix.org left the room. | 00:13:10 |
