darwin.Libsystem: fix existing file error during build

[reckenrode]

Description of changes

After coreutils was updated in #222314, darwin.Libsystem began failing to build in the rework. This appears to be due to a changing in behavior of cp -n to return a non-zero exit code when a file already exists. Note this only affects the reworked stdenv because the current one builds Libsystem with coreutils from the bootstrap tools.

Testing was done with a build of the reworked stdenv bootstrap. For aarch64-darwin, I manually built darwin.libmalloc and confirmed it was building from the newer version. Since aarch64-darwin is not building a source SDK, these headers are not used, but it is ready if/when that it does.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• 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/)
• 23.11 Release Notes (or backporting 23.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.

[toonn]

To reproduce the error we need to rebuild darwin.Libsystem with Coreutils 9.3. These aren't an explicit dependency but come from stdenv. As reckenrode pointed out, the stdenv, probably erroneously, inherits Coreutils from the previous stage in each stage. This means stdenv just has the Coreutils from the bootstrap tarball at the point where darwin.Libsystem gets built. The final stdenv does have the proper Coreutils tools but similarly inherits darwin.Libsystem so it never ends up being built with the latest Coreutils.

However, since the final stdenv does have the correct version of Coreutils we can just rebuild against that, nix-build --pure --no-out-link -E 'with (import ./. {}); darwin.Libsystem.override { inherit stdenv; }.

[reckenrode]

@toonn I updated the PR to reflect that this is a Libsystem issue caused by Libc rather than a Libc issue alone. I also tested using the command you provided and can confirm it reproduces the error using the current stdenv.

$ nix-build --pure --no-out-link -E 'with (import ./. {}); darwin.Libsystem.override { inherit stdenv; }' --system x86_64-darwin
@nix { "action": "setPhase", "phase": "unpackPhase" }
unpacking sources
unpacking source archive /nix/store/85zm06baw94yi7cz4nmr9yynqdrsigcw-Libsystem-1238.60.2.tar.gz
source root is Libsystem-Libsystem-1238.60.2
setting SOURCE_DATE_EPOCH to timestamp 1633495754 of file Libsystem-Libsystem-1238.60.2/xcodescripts/linker_arguments.sh
@nix { "action": "setPhase", "phase": "patchPhase" }
patching sources
@nix { "action": "setPhase", "phase": "configurePhase" }
configuring
no configure script, doing nothing
@nix { "action": "setPhase", "phase": "installPhase" }
installing
cp: not replacing '/nix/store/g65n8z3fgvy8dld580d53nqakv43g7ka-Libsystem-1238.60.2/include/./setjmp.h'

[toonn]

LGTM

Builds both with and without the override when on a4d88ee it only built without the override.