Change:
extraRustcOpts buildTests codegenUnits; }; dontStrip = !release; <ins> # We need to preserve metadata in .rlib, which might get stripped on macOS. See https://github.com/NixOS/nixpkgs/issues/218712 stripExclude = [ "*.rlib" ]; </ins> installPhase = installCrate crateName metadata buildTests; # depending on the test setting we are either producing something with bins

Discussion:
Darwin's v973 appears to break rust files. The previous shipped version (v949) didn't break anything, but that may have been accidental. If you set in the cfg-if derivation, the build succeeds. The resulting rlib file is likely invalid too, this is just a minimal reproduction. The same derivation builds fine: /nix/store/x5lz2zrq2xkj02xn7mkxm19nknik202k-rustencodingrs-0.8.32 So presumably there's some difference in how works. of got me close, but many commits needed skipping due to unrelated issues. The best I could get is: Oldest working commit: (oct 1 2022) Earliest failing commit: (oct 20 2022) The most relevant looking commit in that range is: The derivation from the above nixpkgs commits are: /nix/store/a5ac77k6289sgbq5izv66djgsvabzhc4-cctools-port-973.0.1 /nix/store/mz472jcxzy73rw8297zabcczns3gmjf6-cctools-port-949.0.1 Assuming that's the culprit, I copied the non-stripped and manually ran using both these implementations. This confirms that v973 appears to be the culprit - the v949 version results in a section while v973 removes it. I note that the strip command prints . Based on , it looks like the earlier version bails and essentially does nothing, while the later version proceeds to do more stripping on an already-stripped file, resulting in the .rmeta section being removed. should we never strip files? It says they're already stripped, maybe stripping isn't relevant to this kind of file? is it a bug that darwin's removes the section, and this should be perfectly fine? ... other options?

<details<summary<h2Inspection details</h2</sumary<pre$ ar -p "/nix/store/z2ann7q20qfzipfr87cqm3qwmli7i3zd-rustcfgif-1.0.0-lib/lib/libcfgif-" $ otool -l Load command 0 cmd LCSEGMENT64 cmdsize 72 segname vmaddr 0x0000000000000000 vmsize 0x0000000000000000 fileoff 0 filesize 0 maxprot 0x00000007 initprot 0x00000007 nsects 0 flags 0x0 Load command 1 cmd LCSYMTAB cmdsize 24 symoff 0 nsyms 0 stroff 176 strsize 8 Load command 2 cmd LCDATAINCODE cmdsize 16 dataoff 176 datasize 0 </preNote there's no section. With to the cfg-if derivation, I get: Load command 0 cmd LCSEGMENT64 cmdsize 152 segname vmaddr 0x0000000000000000 vmsize 0x0000000000001883 fileoff 208 filesize 6275 maxprot 0x00000007 initprot 0x00000007 nsects 1 flags 0x0 Section sectname .rmeta segname DWARF addr 0x0000000000000000 size 0x0000000000001883 offset 208 align 2^0 (1) reloff 0 nreloc 0 flags 0x02000000 reserved1 0 reserved2 0 Load command 1 cmd LCSYMTAB cmdsize 24 symoff 6488 nsyms 0 stroff 6488 strsize 1 </pre</details
Related issues: (seems like a duplicate, it was even found via the same cfg_if crate) cctools update PR a different bug in strip a different bug in strip
One from is to add a list, which would be used to exclude specific files via arguments. The most correct fix seems to be "don't ever strip .rlib files", so it's a natural use case for this feature.

For those who want a fix while we wait for the PR to land, you can add the following overlay: This breaks using from crate2nix but I'm sure someone else can figure out how to fix that...
Or even better, you can apply this patch to your nixpkgs (couldn't figure out a way to make this an override):
Created a PR to (finally) fix this