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.
This commit is contained in:
sternenseemann 2022-01-07 02:25:17 +01:00
parent 75e9b9b058
commit 17c5a15c89

View File

@ -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