catboost: use llvm 14 for cuda

[RossComputerGuy]

Description of changes

Upgrade to a newer LLVM version for CUDA (related #305146), format so CI doesn't complain.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[SomeoneSerge]

Yeah ideally we'd accommodate in cudaPackages (the same logic that handles gcc version ranges) but admittedly that might take a non-trivial refactoring and it's ok to postpone it. CC @NixOS/cuda-maintainers

[emilazy]

See #370663 (comment).

[RossComputerGuy]

Is catboost/catboost#2540 still a problem? I tried bumping CUDA to 12 but ran into errors like this:

catboost>   /nix/store/ccm40rk4zlaarhqncxrfmav3yxkrf89h-glibc-2.40-36-dev/include/bits/string_fortified.h(107):
catboost>   error: linkage specification is incompatible with previous "stpncpy"
catboost>   (declared at line 499 of
catboost>   /nix/store/ccm40rk4zlaarhqncxrfmav3yxkrf89h-glibc-2.40-36-dev/include/string.h)
catboost>
catboost>
catboost>      stpncpy (char * const __attribute__ ((__pass_object_size__ (2 > 1))) __dest, const char *__src, size_t __n) noexcept (true)
catboost>      ^

[SomeoneSerge]

Is catboost/catboost#2540 still a problem? I tried bumping CUDA to 12 but ran into errors like this

I didn't check but I'd not expect this to change: they use a higher level tool (yatool) to generate CMakeLists that hard-code most of the relevant parameters

[RossComputerGuy]

I've brought up the CUDA 11 thing with upstream - catboost/catboost#2755. I don't consider it a blocker for this PR. I'm mainly worried about getting things off LLVM 12.

[andrey-khropov]

Is catboost/catboost#2540 still a problem? I tried bumping CUDA to 12 but ran into errors like this:

catboost>   /nix/store/ccm40rk4zlaarhqncxrfmav3yxkrf89h-glibc-2.40-36-dev/include/bits/string_fortified.h(107):
catboost>   error: linkage specification is incompatible with previous "stpncpy"
catboost>   (declared at line 499 of
catboost>   /nix/store/ccm40rk4zlaarhqncxrfmav3yxkrf89h-glibc-2.40-36-dev/include/string.h)
catboost>
catboost>
catboost>      stpncpy (char * const __attribute__ ((__pass_object_size__ (2 > 1))) __dest, const char *__src, size_t __n) noexcept (true)
catboost>      ^

This does not look like an error caused by unsupported CUDA architecture related to catboost/catboost#2540. This is something else.

In conda catboost is built successfully with CUDA 12.0 (and CUDA 12.1 and 12.2 should work as well) using patching CMakeLists by removing unsupported architectures like this:

https://github.com/conda-forge/catboost-feedstock/blob/234a16cbeeeb12bb02bb3eff7282a1cbce9c979f/recipe/build.sh#L57

Static vs shared CUDA libraries could also be an issue (but it does not depend on CUDA version): https://github.com/conda-forge/catboost-feedstock/blob/234a16cbeeeb12bb02bb3eff7282a1cbce9c979f/recipe/build.sh#L64-L66

[RossComputerGuy]

Ok, I'm going to definitely just consider the CUDA bump a non-issue for this PR. I don't have the time or knowledge to figure out this problem. My concern has only been getting things off LLVM 12 so we can drop it.