From d6c651f13c4203f6340accceb2f113476e37951b Mon Sep 17 00:00:00 2001 From: Austin Seipp Date: Tue, 26 Nov 2024 17:02:02 -0600 Subject: [PATCH] nix: fix usage of new parallel linker in Darwin devShell As reported by @lilyball on Discord, the recent nixpkgs update this week brought with it an entirely new Darwin stdenv, which had a behavioral change versus the prior one, causing builds inside the developer shell to fail, as the new super-duper parallel linker could not be used. However, rather than giving up and throwing away *billions* of precious CPU cycles, @emilazy and @lilyball instead doubled down and diagnosed the issue. The result is a new impenetrable line of Nix code, which is fully explained by the comments within. Signed-off-by: Austin Seipp --- flake.nix | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/flake.nix b/flake.nix index d0d635077b..6021840ccc 100644 --- a/flake.nix +++ b/flake.nix @@ -60,7 +60,14 @@ if pkgs.stdenv.isLinux then [ "-fuse-ld=mold" "-Wl,--compress-debug-sections=zstd" ] else if pkgs.stdenv.isDarwin then - [ "-fuse-ld=/usr/bin/ld" "-ld_new" ] + # on darwin, /usr/bin/ld actually looks at the environment variable + # $DEVELOPER_DIR, which is set by the nix stdenv, and if set, + # automatically uses it to route the `ld` invocation to the binary + # within. in the devShell though, that isn't what we want; it's + # functional, but Xcode's linker as of ~v15 (not yet open source) + # is ultra-fast and very shiny; it is enabled via -ld_new, and on by + # default as of v16+ + [ "--ld-path=$(unset DEVELOPER_DIR; /usr/bin/xcrun --find ld)" "-ld_new" ] else [ ];