In reply to @hexa:lossy.network
Artturin: what is your plan with the staging-23.05 backport here? https://github.com/NixOS/nixpkgs/pull/192459#event-10971886154

In reply to @raitobezarius:matrix.org
does the stdenv people knows why checkMeta might have missed those: https://github.com/NixOS/nixpkgs/pull/272199 ?

Hi! We've been using something relatively ugly in cudaPackages because the "cuda compiler driver" usually needs an old gcc, but the libraries it produces need to co-exist with the normal nixpks shared libraries in the same process, and so they need to link against the same c++ standard library. It's like with clang using libstdc++, only the old gcc in place of clang.

I now consider using this uglyness outside cudaPackages because e.g. tensorflow also has some ideas about which compilers it's compatible with. I was suggested that instead of introducing new attributes or changing the meaning of attributes like gccXXStdenv I write a "stdenv adapter".

The hack is (ab)using wrapCCWith with gccForLibs. One bit I'm unsure of is whether I should pass wrapCC the target stdenv's wrapped cc, or the unwrapped one: https://github.com/NixOS/nixpkgs/pull/275947/commits/30016f9c4622fca0145e9904f471079e9393eff1#diff-cea9c91ed8344102b5d5fbf28eae400b8182d3b51d718f88345de8c7a187165fR243

We've been using the unwrapped one so far (because it didn't matter), but I wonder if discarding the old wrappers flags&c is the right thing to do in the general case? This suggests the 2nd question, do wrapCCs compose?