{cc,bintools}-wrapper: Prevent NIX_HARDENING_ENABLE clobbers

[Ericson2314]

We've been doing the "suffix salt" for this variable like the others, but we never bothered setting role-specific variables in the setup hook.

Translation from obscure gobbledygoop: if you are using something like buildPackage.stdednv.cc, it might want (for the build platform) more formatting than the host platform supports, and then all hell breaks loose. Now the build platform-targetting compiler will use NIX_HARDENING_ENABLE_FOR_BUILD and there will be no conflict.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[risicle]

Any changes needed in mkDerivation too?

[Ericson2314]

@risicle That would be a good idea, but that should come separately. In the meantime it will just affect the host platform, which is fine. (And all of them during native compilation.)

[RossComputerGuy]

Just got around to testing if this PR builds the Linux kernel on aarch64-linux for LLVM. I seem to run into a weird failure:

error:
       … in the condition of the assert statement
         at /nix/store/981jbarpm02012h7z33frfv0hm5nj526-source/lib/customisation.nix:417:9:
          416|       drvPath =
          417|         assert condition;
             |         ^
          418|         drv.drvPath;

       … while evaluating a branch condition
         at /nix/store/981jbarpm02012h7z33frfv0hm5nj526-source/pkgs/stdenv/generic/check-meta.nix:504:6:
          503|       inherit (validity) valid;
          504|   in if validity ? handled then validity else validity // {
             |      ^
          505|       # Throw an error if trying to evaluate a non-valid derivation

       … while evaluating the option `settings':

       … while evaluating definitions from `pkgs/os-specific/linux/kernel/common-config.nix':

       (stack trace truncated; use '--show-trace' to show the full, detailed trace)

       error: undefined variable 'isLoongarch64'
       at /nix/store/981jbarpm02012h7z33frfv0hm5nj526-source/pkgs/os-specific/linux/kernel/common-config.nix:512:51:
          511|           || (lib.versionAtLeast version "6.2" && isAarch64 && !stdenv.cc.isClang)
          512|           || (lib.versionAtLeast version "6.5" && isLoongarch64 && !stdenv.cc.isClang)
             |                                                   ^
          513|           || (lib.versionAtLeast version "6.10" && isRiscV64 && !stdenv.cc.isClang)

I also tried removing that line and got a build failure in coreutils. This was done inside a nixpkgs-review shell.

[risicle]

I'm not sure how edits to three bash files would cause a nix eval error - guessing this is a merge/rebase conflict somewhere?

[RossComputerGuy]

Maybe but nixpkgs-review merges right? Or does it only do a merge test?