Commit fa8b6b8e authored by Adam Joseph's avatar Adam Joseph
Browse files

libcCross: set to `null` rather than using `assert` in nonsense scenarios 

As discussed in

  https://discourse.nixos.org/t/help-me-understand-two-load-bearing-assert-statements/51420

The assertion here tickles (via wine, which is always the biggest headache for
our cross-compilation machinery) a `tryEval` that silently drops any outputs
that `throw` while splicing.

In this case, the `gcc.libgcc` output is `throw`ing due to checking if
`libcCross==null`.  The same effect is had by simply setting `libcCross` to
`null` in that situation, and this way we don't have to lean on `tryEval`.
parent 0e0665d1

pkgs/top-level/all-packages.nix

+4 −1
Original line number Diff line number Diff line
@@ -20297,7 +20297,10 @@ with pkgs; 
    else if name == "relibc" then targetPackages.relibc or relibc

    else throw "Unknown libc ${name}";













  libcCross = assert stdenv.targetPlatform != stdenv.buildPlatform; libcCrossChooser stdenv.targetPlatform.libc;













  libcCross =













    if stdenv.targetPlatform == stdenv.buildPlatform













    then null













    else libcCrossChooser stdenv.targetPlatform.libc;





























  threadsCross =















    lib.optionalAttrs (stdenv.targetPlatform.isMinGW && !(stdenv.targetPlatform.useLLVM or false)) {