Skip to content

wrapGAppsHook taints build environment with wrong/its stdenv #172249

@OPNA2608

Description

@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

Bildschirmfoto von 2022-05-09 22-04-43

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`

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions