wrapCCWith: rely on the new bintools attribute for default value

wrapCCWith shipped its own, but imperfect duplication of the logic we
use to choose the bintools for the *next* stage by inspecting
targetPlatform.

This change should ensure that C compilers relying on the default
behavior of wrapCCWith should end up with the same bintools als
theirStage.bintools. In particular, this makes
pkgsLLVM.llvmPackages.stdenv correctly use the LLVM bintools instead of
GNU binutils.

1 files changed, 5 insertions, 1 deletions

diff --git a/pkgs/top-level/all-packages.nix b/pkgs/top-level/all-packages.nix
index d3aa3479d13d9..8ce2176df0d56 100644
--- a/pkgs/top-level/all-packages.nix
+++ b/pkgs/top-level/all-packages.nix
@@ -13271,7 +13271,11 @@ with pkgs;
       # Others should instead delegate to the next stage's choice with
       # `targetPackages.stdenv.cc.bintools`. This one is different just to
       # provide the default choice, avoiding infinite recursion.
-      bintools ? if stdenv.targetPlatform.isDarwin then darwin.binutils else binutils
+      # See the bintools attribute for the logic and reasoning. We need to provide
+      # a default here, since eval will hit this function when bootstrapping
+      # stdenv where the bintools attribute doesn't exist, but will never actually
+      # be evaluated -- callPackage ends up being too eager.
+      bintools ? pkgs.bintools
     , libc ? bintools.libc
     , # libc++ from the default LLVM version is bound at the top level, but we
       # want the C++ library to be explicitly chosen by the caller, and null by