Change:
<ins> # On Mac OS X, frameworks are linked to the system CoreFoundation but # dynamic libraries built with nix use a pure version of CF this # causes segfaults for binaries that depend on it at runtime.  This # can be solved in two ways. # 1. Rewrite references to the pure CF using this setup hook, this # works for the simple case but this can still cause problems if other # dependencies (eg. python) use the pure CF. # 2. Create a wrapper for the binary that sets DYLD_FRAMEWORK_PATH to # /System/Library/Frameworks.  This will make everything load the # system's CoreFoundation framework while still keeping the # dependencies pure for other packages. fixupOutputHooks+=('fixDarwinFrameworksIn $prefix') fixDarwinFrameworks() { local systemPrefix='/System/Library/Frameworks' for fn in "$@"; do if [ -L "$fn" ]; then continue; fi echo "$fn: fixing dylib" for framework in $(otool -L "$fn" | awk '/CoreFoundation.framework/ {print $1}'); do install_name_tool -change "$framework" "$systemPrefix/CoreFoundation.framework/Versions/A/CoreFoundation" "$fn" >&2 done done } fixDarwinFrameworksIn() { local dir="$1" fixDarwinFrameworks $(find "$dir" -name "*.dylib") } </ins>

Discussion:
libnfc from the cache does not seem to work for me: ~ What happens is a null-pointer dereference somewhere inside IOKit: ~ I am really not sure what is going on, but what troubles me is that I cannot reproduce the build on my laptop: apparently, the examples depend on readline, which is not listed as a dependency. ~ How does the manage to succeed on Hydra? What’s wrong with libnfc or libusb built on Hydra? After I as a dependency the build succeded and the resulting libnfc is fully functional.
Do you use sandboxing?
I honestly do not know how it works and if it is enabled by default.
I have opened to address the readline issue (which is probably completely unrelated).
I ask because it could account for the difference (that is, there could be an impurity in the build, causing it to break in unsandboxed environments EDIT: or allowing it to succeed, whichever). It's not enabled by default, but I'm not sure about how stuff works on MacOS wrt sandboxing.
Hm, you have a point. I guess it’s not sandboxing but something similar: building in a pure nix-shell yields non-functional utils.
Ok, now I see. Without it found Homebrew (as the expression does not depend on and therefore the system is not shadowed) and it told it about libusb installed from Homebrew. So, apparently libusb is the culprit.
On my end, I've found that with to the build environment, the readline error manifests (whereas it builds fine otherwise); adding both & allows it to build. There's no segfault, however. As a side note, FWIW, is much weaker than the isolation provided by the build sandbox (it just clears most of the shell environment, you can still traverse the rootfs & pick up all sorts of impurities).
How did you build this? Do you see the same result with ?
Try running: in your nix-shell. see
We need some proper way to fix that.
We could have it set in at least temporarily. There are no real side effects to just setting it besides the potential impurities.

I spent most of yesterday trying to debug the issue but with no luck: I did not manage to build libusb and libnfc with debug symbols (I have no idea how works on macOS; apparently it puts debug symbols into but does not copy them to the resulting binary, therefore, when the library is installed into the store, debug symbols are gone. It would be great if someone taught me how to do this properly).
What exactly is that impure thing that makes pull system CF?
In this case it's the framework, that's linked against the system CoreFoundation, I'm still testing some stuff but I'm pretty sure that I have a proper solution.