wrapGAppsHook taints build environment with wrong/its stdenv

[OPNA2608]

Describe the bug

Summary:

Including wrapGAppsHook in the nativeBuildInputs of a derivation X that uses a non-standard stdenv (i.e. stdenv = gcc10Stdenv;) taints derivation X's environment with the compiler that is used by (presumably) makeBinaryWrapper, causing the wrong compiler to get used by the build.

---

Hit this while trying to unbreak palemoon. Our default compiler right now is GCC11, which the packaged version of Pale Moon doesn't support.

(For slightly complicated reasons, the Pale Moon version we have packaged isn't technically the latest version some of the online docs assume, but it is the recommended one. We could bump the package, but I'd rather wait until the next good version is released. See #165221 for more details.)

Since the packaged version is only compatible with up to GCC10, I tried to change the all-packages.nix entry to

palemoon = callPackage ../applications/networking/browsers/palemoon {
  stdenv = gcc10Stdenv;
};

This makes the Nix-level asserts pass (which check stdenv.cc.version for license compliance reasons), but the compiler the build actually ends up using is GCC11, which leads to a failed build.

78 0:04.10(B checking for the target C compiler... /nix/store/bg35nfwn6zd616facdywiysgpprfvsji-gcc-wrapper-11.3.0/bin/gcc

Turns out that the culprit is wrapGAppsHook which seems to insert its GCC before the desired stdenv's GCC. which -a gcc inside palemoon's postPatch returns:

/nix/store/bg35nfwn6zd616facdywiysgpprfvsji-gcc-wrapper-11.3.0/bin/gcc <--- This is stdenv.cc
/nix/store/i633yj06994wbb89b88nm5kb4pbm8h4r-gcc-11.3.0/bin/gcc
/nix/store/f9i4i4fw4l7pbxkl9zn7rfps4mnp1nw5-gcc-wrapper-10.3.0/bin/gcc <--- This is the requested gcc10Stdenv.cc
/nix/store/fiqdwkhqbvp9wfj5n66i9fjqicsygvwa-gcc-10.3.0/bin/gcc

Steps To Reproduce

A minimal reproducer (on a checkout of eb935d1):

nix-build -E '
  with import ./. { };
  (hello.overrideAttrs (oa: {
    postPatch = "echo ${gcc10Stdenv.cc.version} && gcc --version && exit 21";
    # nativeBuildInputs = [ wrapGAppsHook ];
  })).override {
    stdenv = gcc10Stdenv;
  }
'

Yields the expected output.

10.3.0
gcc (GCC) 10.3.0

Uncommenting the nativeBuildInputs yields:

10.3.0
gcc (GCC) 11.3.0

I'll push an expected-to-work PR for palemoon shortly, which would be a more complicated reproducer of this.

Expected behavior

Builds should use the compiler they are told to use.

Screenshots

Additional context

It looks like wrapGAppsHook was recently migrated to the new makeBinaryWrapper via #164163. That seems like the most likely culprit to me.

Notify maintainers

CC @ncfavier (author of #164163)

Metadata

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

[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 5.15.2-xanmod1-tt, NixOS, 21.11 (Porcupine)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.16`
 - channels(bt1cn): `"unstable-22.05pre375061.c777cdf5c56"`
 - channels(root): `"nixos-21.11.337127.f0d8b069143"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

[ncfavier]

The problem seems to be that cc was added to makeBinaryWrapper's deps in #150079. Removing it makes your reproducer give the expected output.

It was apparently added to fix issues on aarch64-darwin, though the error logs are gone. I'll try to reproduce the errors in a test PR.

EDIT:

libc++abi: terminating with uncaught exception of type std::runtime_error: Failed to spawn codesign_allocate: No such file or directory
/nix/store/0zrljp1ph80sz8qdr27w4cc4s8dphbas-post-link-sign-hook: line 2: 84994 Abort trap: 6           CODESIGN_ALLOCATE=codesign_allocate /nix/store/wa5xzmvj3a1hg751p9dicy6jgalbbjc3-sigtool-0.1.2/bin/codesign -f -s - "$linkerOutput"
collect2: error: ld returned 134 exit status

ping @bergkvist

[ncfavier]

Seems like we're hitting #148189. Maybe we can add cc or cctools to deps only on aarch64-darwin for the time being.

[bergkvist]

I remember I was stuck on that codesign_allocate error for some time while working on the fix for aarch64-darwin - and that adding cc to deps made the error go away. I don't think I dug much deeper into the underlying cause after that.

[ncfavier]

Based on my tests, adding cctools to deps on aarch64-darwin is enough to make the tests pass. Hopefully that's acceptable regarding the current issue.

I'll make a PR soon. EDIT: #172366

[ncfavier]

Note that this had to be unfixed on aarch64-darwin for now: #174038