add setup-hook to fix darwin frameworks

[LnL7]

Motivation for this change

Dynamic libraries built with nix use a pure version of CF, this can cause issues when it also depends on frameworks.

Fixes #22450, #20484

Packages that are fixed by this without setting DYLD_LIBRARY_PATH with a wrapper.

• gnupg
• graphviz
• libnfc
• libusb
• racket
• python-pyqt (python depends on the pure CF)

Things done

• Tested using without xcode
• Built on platform(s)
  • macOS
• Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Fits CONTRIBUTING.md.

---

/cc @copumpkin @pikajude @johbo

[LnL7]

Should this be propagated?

[copumpkin]

Yeah, I guess

[copumpkin]

I don't understand how this works. A big flavor of issue is:

1. Package A gets built against pure CF and works just fine on its own
2. Package B depends on A and gets built against an impure framework that depends on /System/Library/Frameworks/CoreFoundation.framework

Now, if data gets passed inside B from A to the impure framework, you'll get a segfault.

So my question: would this build hook get applied to A, B or both? If it's just B, I don't think it'll fix things. If it's both, it will, but that's equivalent to just making pure CF into an impure symlink. Just A isn't a particularly meaningful option 😄

The reason I keep suggesting DYLD_LIBRARY/FRAMEWORK_PATH is that it gives B an opportunity to override A's decision, without messing with A's files (which by that point are immutable in the store).

[LnL7]

If I understand how all this works correctly this shouldn't be used for A in that example. But there are some libraries like libusb that depend on (impure) frameworks that are basically just broken. Even if they are used in a context that does not use the pure CF.

[johbo]

I've tried to apply this in the context of pygtk, tryton and xournal, without success. Think that I would have to apply it in the dependencies of them, but then it's kind of the same as making CF impure for everything.

Starting to think that the wrapper approach for applications on a case by case base is probably the best we can do at the moment.

[copumpkin]

Relevant: #23018

[copumpkin]

Transcribing my comments from IRC:

[09:52:05]  <copumpkin>	LnL: anyway, I don't know. I guess it's good that it makes more things work :)
[09:55:35]  <copumpkin>	LnL: maybe add a comment to the hook script discussing (at a high level) when this will work and when it won't, perhaps linking to the PR for people who want more information?
[09:56:22]  <copumpkin>	LnL: issue is just stuff like what johbo says; people are going to try to use it on things, and more often than not, something will import CF

[copumpkin]

👍

[jbaum98]

Is there a reason why we force the use of impure CF? Why can't we just make sure all the programs use the pure CF?

[copumpkin]

The pure CF doesn't really match the impure one featurewise. It will once https://github.com/apple/swift-corelibs-foundation/tree/master/CoreFoundation becomes the default and we can build it as part of our stdenv, but until then, a lot of the magic features in CF like toll-free bridging don't work on our pure one but lots of the standard Apple frameworks assume it.