Move to cuda 12.6

[isuruf]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

cc @jakirkham @carterbox @mariusvniekerk @h-vetinari

Closes #6630

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/meta.yaml) and found it was in an excellent condition.

[jakirkham]

As noted previously, this won't work for linux_ppc64le, which stops at CUDA 12.4. So that will need to be broken out

[h-vetinari]

Thanks for the PR. I'd still prefer a dedicated migration for this, but I guess we can bump and see as well 🤷

[hmaarrfk]

Did ppc get dropped from upstream?

[jakirkham]

Yes it was deprecated in CUDA 12.4 and removed in CUDA 12.5

Edit - Also linking this tracking issue: conda-forge/cuda-feedstock#27

[bdice]

It would be nice to point recipe maintainers towards the guide we wrote for CUDA recipe maintainers, specifically around CUDA Enhanced Compatibility so that packages can be backwards compatible (use a newer compiler to build but run with an older CUDA Toolkit). If we do end up rolling this back or adding a migrator, it would be good to link to this: https://github.com/conda-forge/cuda-feedstock/blob/main/recipe/doc/recipe_guide.md#cuda-enhanced-compatibility

[carterbox]

Suggested change

	- 12.4 # [linux and ppc64le and os.environ.get("CF_CUDA_ENABLED", "False") == "True"]
	- 12.4 # [ppc64le and os.environ.get("CF_CUDA_ENABLED", "False") == "True"]

ppc64le implies Linux.

https://docs.conda.io/projects/conda-build/en/latest/resources/define-metadata.html#preprocessing-selectors

[isuruf]

It's better to be explicit

[hmaarrfk]

Do we need to bump the cos image used for 12.6. I keep getting errors that imply that the wrong start is pulled in for 12.6 packages

[h-vetinari]

that the wrong start is pulled in for 12.6 packages

What do you mean by "start"? Some bits of the infra (esp. on aarch) already depend on glibc 2.28, but that's true even for the CUDA 12.0 bits. That will soon be solved by #6626, which is essentially ready to merge (though you could help in reviewing the announcement).

[h-vetinari]

OK, the image changes are in, let's rock 'n' roll!

[h-vetinari]

I just realised - bumping to 12.6 means we should have updated GCC pins as well. The upstream docs (found the reference in conda-forge/nvcc-feedstock#51) say that nvcc compatible with "GCC 6.x - 13.2". We're on 13.3 though.

@jakirkham @bdice @carterbox, is the minor-level bound really enforced? I don't remember that in previous nvcc constraints for gcc (which were major-only AFAIR).

Opened an issue for discussion, see below.

[carterbox]

> NVCC performs a version check on the host compiler’s major version and so newer minor versions of the compilers listed below will be supported, but major versions falling outside the range will not be supported.

I would assume that the minor version specification means that this is the one they have tested.