NVCC dictates the host C++ compiler version we use to build CUDA programs, and often drifts behind the nixpkgs' stdenv. At the time of writing nixpkgs' default nvcc uses gcc11, but the stdenv on linux is already at gcc12. When we pass gcc11 to NVCC the naive way the builds pick up gcc11's older libstdc++ and we face runtime issues when dynamically linking normal nixpkgs libraries which expect the newer libstdc++: #220341. For this reason we want the CUDA programs built with GCC11 (or whichever toolchain is pinned) to link a libstdc++ compatible with the rest of nixpkgs. Apparently this is also what nixpkgs llvm toolchains do, because libraries linked against libc++ could not have co-existed with those linked against libstdc++
To accommodate that we currently abuse the libcxx argument of wrapCCWith: https://github.com/SomeoneSerge/nixpkgs/blob/8fd02ce2c20b8c7f6b7be39681cdf71a5b4847e2/pkgs/development/compilers/cudatoolkit/stdenv.nix#L14-L20
This actually has worked for a number of packages, cf. #223664, but for absolutely accidental reasons: wrapCCWith propagates libcxx to downstream packages' buildInputs and cc happily picks it up. Unless it doesn't: #225661, #224150 (comment)
The better solution would be to adjust cc-wrapper to our needs, as discussed in #225661 (comment)
NVCC dictates the host C++ compiler version we use to build CUDA programs, and often drifts behind the nixpkgs' stdenv. At the time of writing nixpkgs' default nvcc uses gcc11, but the stdenv on linux is already at gcc12. When we pass gcc11 to NVCC the naive way the builds pick up gcc11's older libstdc++ and we face runtime issues when dynamically linking normal nixpkgs libraries which expect the newer libstdc++: #220341. For this reason we want the CUDA programs built with GCC11 (or whichever toolchain is pinned) to link a libstdc++ compatible with the rest of nixpkgs. Apparently this is also what nixpkgs llvm toolchains do, because libraries linked against libc++ could not have co-existed with those linked against libstdc++
To accommodate that we currently abuse the
libcxxargument ofwrapCCWith: https://github.com/SomeoneSerge/nixpkgs/blob/8fd02ce2c20b8c7f6b7be39681cdf71a5b4847e2/pkgs/development/compilers/cudatoolkit/stdenv.nix#L14-L20This actually has worked for a number of packages, cf. #223664, but for absolutely accidental reasons:
wrapCCWithpropagateslibcxxto downstream packages'buildInputsandcchappily picks it up. Unless it doesn't: #225661, #224150 (comment)The better solution would be to adjust cc-wrapper to our needs, as discussed in #225661 (comment)