Remove CUDA 11?

[keysmashes]

Currently, nix search still prints the warning trace: evaluation warning: CUDA versions older than 12.0 will be removed in Nixpkgs 25.05; see the 24.11 release notes for more information. Since breaking changes for 25.05 will be restricted quite soon (#393359), and CUDA 11 is still present, I'm filing this in case the removal of CUDA 11 has been forgotten.

Apologies if there is already an issue/PR open for this, or if y'all are already on top of it!

@NixOS/cuda-maintainers

[ConnorBaker]

The warning was added in #342112 with the understanding that the required GCC releases would be unavailable.

@emilazy is it still the plan to drop GCC releases prior to 12? My understanding was that decision was based on GCC 15 being available — does it look like GCC 11 lives a bit longer?

[ConnorBaker]

To add on a bit more, it would make my life easier if we continued to have those GCC/CUDA releases for one more release!

[keysmashes]

Since branch-off has now happened (and breaking changes have been restricted for over three weeks), is it safe to assume CUDA 11 will not be removed in 25.05?

[ConnorBaker]

I’m planning on moving releases prior to 11.8 out of tree to nix-community/cuda-legacy shortly (time permitting).

11.8 will be a little more tricky as there are still packages in-tree which use it.

[emilazy]

I gave an overview of the remaining users in #342112 and they all looked easy to deal with except for TensorFlow. Hopefully more have not been added since. DCGM might need patching to mirror its CUDA 10 drop for 11. tensorflow-bin is default now and the source build is very outdated, so it can presumably be marked as broken. I don’t know if there has been movement on the PRs to bring the source build up to date. (It also depends on an EOL Bazel which should really be dropped.)

[ConnorBaker]

@emilazy maybe this will need a longer discussion in the stdenv matrix, but any idea the level of effort involved in vendoring the required versions of GCC needed out of tree (10 and 11, I believe)?

[emilazy]

Probably not that hard assuming you don’t need the rest of the package set to keep compatibility with them, but I assume that shouldn’t block something that was already agreed to happen a release ago?

[ConnorBaker]

Yep! Just curious about the work I have ahead of me :)

[emilazy]

I think that in isolation GCC should act pretty much like "any other package" and that much of the complexity is in the initial bootstrap that wouldn't be relevant for you. But of course the main things you lose are the things that incur the maintenance burden of old compilers to begin with - adapting changes intended for newer versions to them, keeping the compilers themselves building with newer toolchains, mai tai ING support for packages using them including older versions of dependencies where required, and so on. The more standalone your use case is the more likely it is to be practical, especially if you only need to support one platform, one configuration, etc.; I'm not familiar enough with CUDA internals to say what the likely challenges would be.