From 4c55d5401992c46c9c373741c74c71423f57489d 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..04a96f8d34 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 we actually want to use the newer Xcode linker + # instead (unfortunately not yet open source) which is ultra-fast and + # very shiny; it is enabled via -ld_new + [ "-fuse-ld=ld" "--ld-path=$(unset DEVELOPER_DIR; /usr/bin/xcrun -find ld)" "-ld_new" ] else [ ];