fix c_stdlib_version zip with cdt_name

[h-vetinari]

Follow-up to #5592

This tries to match the setup of the linux selectors with cdtname:

conda-forge-pinning-feedstock/recipe/conda_build_config.yaml

Lines 123 to 132 in 595a16b

	cdt_name: # [linux]
	- cos6 # [linux64 and os.environ.get("DEFAULT_LINUX_VERSION", "cos6") == "cos6"]
	- cos7 # [linux64 and os.environ.get("DEFAULT_LINUX_VERSION", "cos6") == "cos7"]
	- cos7 # [linux and aarch64]
	- cos7 # [linux and ppc64le]
	- cos7 # [linux and armv7l]
	- cos7 # [linux and s390x]
	- cos7 # [linux and os.environ.get("CF_CUDA_ENABLED", "False") == "True"]
	- cos7 # [linux and os.environ.get("CF_CUDA_ENABLED", "False") == "True"]

CC @beckermr @jakirkham @isuruf

[conda-forge-webservices]

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) and found it was in an excellent condition.

[jakirkham]

Thanks Axel! 🙏

Do we need to do this with c_stdlib too as it is also zipped?

Think we may also need to add both of these to the CUDA 12 migrator as well

[h-vetinari]

Do we need to do this with c_stdlib too as it is also zipped?

I don't believe so; for example, c_compiler, is part of the same zip as well but has no extra lines for CF_CUDA_ENABLED or in cuda120.yaml. That's because the zip itself changes based on CF_CUDA_ENABLED

Edit: Nevermind...

[h-vetinari]

Do we need to do this with c_stdlib too as it is also zipped?

So I looked at this again in more detail, and I had wrongly remembered / imagined that c_compiler needed to be zipped with its version. That's why it doesn't have config for CF_CUDA_ENABLED, and why it's not updated as part of the CUDA migrator. I think the same situation applies to c_stdlib, so I've removed that from the zip_keys.

Think we may also need to add both of these to the CUDA 12 migrator as well

Consequently, I've added only c_stdlib_version to cuda120.yaml.

I was kinda expecting the CI here would check matching zip length also for CUDA builds? But in any case, I think this should be good now. I'd propose to merge it and see if it solves the ucx situation.

[beckermr]

@h-vetinari @jakirkham can you all test these changes with relevant feedstocks before merging?

[jakirkham]

Yes am planning to test. Just have been in meetings most of the day

[h-vetinari]

AFAIU it's not possible to fully test this because the change in the zip_keys will only apply once the global pinning is updated.

[beckermr]

You can run against the new copy of the config by download it locally and calling

conda-smithy rerender --no-check-uptodate -e conda_forge_pinning.yaml

[h-vetinari]

OK, I can confirm that conda-forge/ucx-split-feedstock#158 can rerender again with the changes from this PR.

Edit: Also tested a non-cuda feedstock (numpy), no problems.

[beckermr]

Thank you!

[jakirkham]

Thanks all! 🙏

This is working smoothly now 😄

[njzjz]

I got the glibc error for cuda12 builds today. It installed sysroot 2.28 instead of 2.17, while the glibc in the image is still 2.17. Finally, I found this PR and realized cuda120.yaml should be updated manually. The update for cuda120.yaml here doesn't affect the downstream feedstocks.

[njzjz]

I got the glibc error for cuda12 builds today. It installed sysroot 2.28 instead of 2.17, while the glibc in the image is still 2.17. Finally, I found this PR and realized cuda120.yaml should be updated manually. The update for cuda120.yaml here doesn't affect the downstream feedstocks.

Wait, it doesn't work...