Repository navigation
darwin binary fails on non-Nix Macs: dyld can't load libiconv.2.dylib from hardcoded /nix/store path (v20.0.10) #1251
Description
Activity
This issue was auto-closed. Issues from new contributors are auto-closed by default.
Maintainers review auto-closed issues and reopen worthwhile ones. Issues that do not meet the quality bar in CONTRIBUTING.md may not be reopened or receive a reply.
Keep the issue short, concrete, and written in your own voice.
If a maintainer replies
lgtmi, your future issues will stay open. If a maintainer replieslgtm, your future issues and PRs will stay open.See CONTRIBUTING.md.
Thank you for this issue. I can confirm that pinning to 19.0.2 works on macOS 26.5.1 (Apple Silicon; w/o
nixinstalled).Confirmed on Darwin 27.0.0 (Apple Silicon, no Nix), v20.0.10. Same load command as reported, and the macOS 26 confirmation above matches: this fails on any Mac without Nix, regardless of OS version.
Root cause is in the Nix build:
package.nixadds nixpkgslibiconvto the darwinbuildInputs, andrelease.yamlpublishes thenix build .#ccusageoutput to npm as-is. Nothing inCargo.lockreferences iconv, so the linkage comes purely from the build environment. The release workflow verifies the Linux binary is static but has no equivalent guard for darwin, which is how the store path shipped unnoticed.I verified the fix at the artifact level: rewriting the load command in the published 20.0.10 binary and re-signing makes it run correctly on a Mac without Nix:
$ install_name_tool -change /nix/store/xvmhkpvfvmy4sfdkqwg9inq3qkpnx81b-libiconv-109.100.2/lib/libiconv.2.dylib /usr/lib/libiconv.2.dylib ccusage $ codesign -f -s - ccusage $ ./ccusage --version ccusage 20.0.10
macOS ships
/usr/lib/libiconv.2.dylibwith the same compatibility version (7.0.0), so the swap is safe.Proposed build fix, the same rewrite at build time plus a guard so it cannot regress:
--- a/package.nix +++ b/package.nix @@ craneLib.buildPackage ( commonArgs // { inherit cargoArtifacts; + # The npm-published darwin binary must run on machines without Nix: + # relink libiconv to the system copy and fail if any store path remains. + postFixup = lib.optionalString stdenv.isDarwin '' + install_name_tool -change ${lib.getLib libiconv}/lib/libiconv.2.dylib /usr/lib/libiconv.2.dylib "$out/bin/ccusage" + if otool -L "$out/bin/ccusage" | grep -q '/nix/store/'; then + echo "error: ccusage still links against Nix store libraries" >&2 + otool -L "$out/bin/ccusage" >&2 + exit 1 + fi + '';
And in
release.yaml, mirroring the existing "Verify Linux binary is static" step:- name: Verify macOS binary has no Nix store references if: matrix.platform == 'darwin' shell: bash run: | otool -L "${{ matrix.binary }}" ! otool -L "${{ matrix.binary }}" | grep '/nix/store/'
One caveat I could not verify locally (no Nix on this machine): on aarch64-darwin the binary needs re-signing after modification. Recent nixpkgs wraps
install_name_toolto re-sign automatically; if that does not hold for the pinned nixpkgs here, the postFixup needs an explicit ad-hoccodesignorautoSignDarwinBinariesHook.Workaround until a fixed release:
npx [email protected](last release before the compiled binaries).Happy to open a PR with the above if approved.
Reacted by akafred- added a commit that references this issue
on Jun 10, 2026 Thank you guys. this is the issue we are migrating into a new ci env.
so sorry!will fix it soon!!!
- added a commit that references this issue
on Jun 10, 2026 guys i hit the publish button. let's see
Reacted by Sean FloydConfirmed fixed on my end. Thanks Ryo!
- added a commit that references this issue
on Jun 11, 2026 Historical audit: this discussion was auto-closed by the legacy contributor gate. That closure did not assess technical importance.
Audit result: resolved. A later merged change or the current
mainimplementation covers this request. This item is kept for history and does not need to be reopened.
[email protected]crashes on launch on any Mac without Nix. The published darwinbinary links libiconv from a
/nix/store/...path that only exists on the build machine:It's a regression in 20.0.10 only. Checking the published binaries with
otool -L:20.0.0–20.0.9: bothdarwin-arm64anddarwin-x64link/usr/lib/libiconv.2.dylib(fine)20.0.10: both link a/nix/store/...libiconv.2.dylibpath (broken)Workaround: pin to
20.0.9(npx [email protected]); its binary links the system libiconv perotool.Tested on Apple Silicon, macOS (Darwin 25.5.0), no Nix installed.