cc-wrapper: chaining multiple wrappers

[SomeoneSerge]

The cc-wrapper, wrapCCWith, currently expects unwrapped compilers and libraries for some of its arguments. There's no documentation explaining whether passing the wrappers in its place is intended to be supported (in the future), and no clear description as to which parts of the wrapper are "public" and may be inspected by downstream derivations. We should either support compositions of cc-wrappers or document them as unsupported. Here are some examples of questionable compositions:

wrapCCWith {
  cc = wrapCCWith ...;
  gccForLibs = wrapCCWith ...;
}

See below for a use-case where composing cc-wrappers might be required.

Old description

An experimental stdenvAdapters.useLibsFrom was introduced in #275947 in order to deal with packages that expect older toolchains than Nixpkgs' default. This includes many "native extensions" in python3Packages (e.g. python3Packages.tensorflow) and packages built with CUDA support. These constraints are often temporary and we see more of those after gcc major version bumps, but they are a hindrance in creating consistent closures.

The reason it's not enough to just build a package with e.g. gcc11Stdenv is that that prevents us from loading shared libraries linked against the newer (Nixpkgs' default) libstdc++ in the same process'es namespace. E.g. this is what people observe when python segfaults depending on the order of imports (e.g. import cv2; import scipy.optimize vs import scipy.optimize; import cv2).

The "stdenv adapter" from #275947 relies on passing the unwrapped cc.cc in wrapCCWith's gccForLibs in order to create a wrapper that uses a package-compatible compiler with the nixpkgs-compatible c++ standard library. This works for the top-level package scope in the default non-cross instantiation of Nixpkgs on *-linux platforms, which use gcc stdenvs by default. The following cannot yet be expected to do anything meaningful:

Steps To Reproduce

1. Inheriting flags unrelated to the stdandard libraries: useLibsFrom pkgs.gcc10Stdenv pkgs.ccacheStdenv (both picked arbitrarily)
2. Inheriting libcxx: useLibsFrom aStdenvThatUsesLibcxx pkgs.gcc10Stdenv (picked arbitrarily)
3. Using useLibsFrom in the cross-compilation setting: the adapter is hard-coded to use pkgs.coreutils instead of inheriting the build platform's coreutils: stdenvAdapters.useLibsFrom: use targetStdenv.cc.override #281371, also matrix

Expected behavior

1. A stdenv that uses gcc10's libstdc++ but ccacheStdenv.cc's extraConfig

2. A stdenv with gcc10 using libc++ by default.

   1. This likely affects all Darwin platforms. I haven't confirmed with python3Packages.tensorflow yet because it's currently marked as broken on isDarwin

Notify maintainers

@amjoseph-nixpkgs @NixOS/cuda-maintainers @rrbutani #282220 (comment)

Metadata

Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.

❯ git rev-parse HEAD
68b63c306a6583d41d03207fb3c8b08abc56c262

---

Add a 👍 reaction to issues you find important.