From 17c5a15c89f2523b2543f946daa4d018e04d731a Mon Sep 17 00:00:00 2001 From: sternenseemann Date: Fri, 7 Jan 2022 02:25:17 +0100 Subject: 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. --- pkgs/top-level/all-packages.nix | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) 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 -- cgit 1.4.1