AArch64 Darwin release binaries link against non-existent `/nix/store` dylibs

[michalrus]

Context & versions

• Release: 2.3.0
• Asset: hydra-aarch64-darwin-2.3.0.zip
• Platform: Apple Silicon macOS (AArch64 Darwin), a clean machine without Nix installed

We pull the official hydra-node release binaries to bundle with another tool, so we run them on plain macOS machines that have never seen Nix. The AArch64 Darwin binaries have a few load commands that point straight into /nix/store, so dyld can't find them and the binary won't start.

This isn't new to 2.3.0 -- the same thing happened in 1.0.0. For that release we worked around it by rebuilding a relocatable bundle ourselves, but it'd be great to get the official artifacts fixed.

Steps to reproduce

1. On a clean Apple Silicon Mac (no Nix), download hydra-aarch64-darwin-2.3.0.zip from the 2.3.0 release.
2. unzip hydra-aarch64-darwin-2.3.0.zip
3. ./hydra-node --version

Actual behavior

dyld kills the process at launch because it can't find a /nix/store dylib, e.g.:

dyld: Library not loaded: /nix/store/9kffgbvhza212ishsam4p8wklh92ih9v-libiconv-109.100.2/lib/libiconv.2.dylib
  Referenced from: ./hydra-node
  Reason: image not found

otool -L shows the offending absolute /nix/store paths (everything else resolves against /usr/lib or the system frameworks just fine):

❯ otool -L hydra-node
hydra-node:
	/usr/lib/libSystem.B.dylib
	/usr/lib/libz.dylib
	/usr/lib/libc++.1.dylib
	/usr/lib/libc++abi.dylib
	/nix/store/9kffgbvhza212ishsam4p8wklh92ih9v-libiconv-109.100.2/lib/libiconv.2.dylib   <-- not on a normal Mac
	/usr/lib/libffi.dylib
	/System/Library/Frameworks/Security.framework/Versions/A/Security

❯ otool -L hydra-tui
hydra-tui:
	/usr/lib/libSystem.B.dylib
	/usr/lib/libz.dylib
	/nix/store/gkf7zxgyfdc6ibmwrgygix52zqxv7gv2-libsodium-vrf-1.0.18/lib/libsodium.23.dylib       <-- not on a normal Mac
	/nix/store/75a274ny3ga0drckv9h08fqvrgw20s14-secp256k1-0.3.2/lib/libsecp256k1.2.dylib          <-- not on a normal Mac
	/nix/store/i8xqlmxskym7gx8q9w6rpd1rbv9h4j3s-ncurses-6.5/lib/libncursesw.6.dylib               <-- not on a normal Mac
	/usr/lib/libc++.1.dylib
	/usr/lib/libc++abi.dylib
	/nix/store/9kffgbvhza212ishsam4p8wklh92ih9v-libiconv-109.100.2/lib/libiconv.2.dylib           <-- not on a normal Mac
	/nix/store/lb7mz349az4l6dixcizj2pdngxghnzik-gmp-with-cxx-6.3.0/lib/libgmp.10.dylib            <-- not on a normal Mac
	/usr/lib/libffi.dylib
	/System/Library/Frameworks/Security.framework/Versions/A/Security

For hydra-node it's just libiconv (which actually exists at /usr/lib/libiconv.2.dylib on macOS, so it's an unnecessary hard-coding). hydra-tui is worse -- libsodium, secp256k1, ncursesw, gmp, and libiconv are all pinned to /nix/store.

There are also a handful of LC_RPATH entries pointing into /nix/store (zlib, lmdb, libcxx, libiconv, libffi), which is less of an issue.

The zip also just contains the two bare executables with no bundled lib/ directory, so there's nothing alongside them to satisfy the missing libraries.

Expected behavior

The AArch64 Darwin release binaries should run on a clean macOS machine without Nix. A couple of ways to get there:

• Rewrite the /nix/store load commands to system equivalents where they exist (libiconv -> /usr/lib/libiconv.2.dylib), and
• for the libraries with no system counterpart (libsodium, secp256k1, ncursesw, gmp), ship them next to the executable and point the load commands at @executable_path/... (or @rpath with a bundled lib/ dir) -- e.g. via something like nix-bundle-exe.