Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add setup-hook to fix darwin frameworks #22571

Merged
merged 2 commits into from Mar 15, 2017

Conversation

LnL7
Copy link
Member

@LnL7 LnL7 commented Feb 8, 2017

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 LnL7 added 2.status: work-in-progress 6.topic: darwin Running or building packages on Darwin labels Feb 8, 2017
stdenv.lib.optional stdenv.isLinux systemd ++
stdenv.lib.optionals stdenv.isDarwin [ libobjc IOKit ];
propagatedBuildInputs = stdenv.lib.optional stdenv.isLinux systemd
++ stdenv.lib.optionals stdenv.isDarwin [ fixDarwinFrameworks libobjc IOKit ];
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be propagated?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I guess

@copumpkin
Copy link
Member

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
Copy link
Member Author

LnL7 commented Feb 10, 2017

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
Copy link
Contributor

johbo commented Feb 18, 2017

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
Copy link
Member

Relevant: #23018

@copumpkin
Copy link
Member

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

@LnL7 LnL7 mentioned this pull request Mar 7, 2017
7 tasks
@LnL7 LnL7 force-pushed the darwin-frameworks-hook branch 2 times, most recently from 7ac75ab to 1cd5e67 Compare March 7, 2017 23:38
@copumpkin
Copy link
Member

👍

@copumpkin copumpkin merged commit 38a0381 into NixOS:master Mar 15, 2017
@LnL7 LnL7 deleted the darwin-frameworks-hook branch March 16, 2017 11:01
@LnL7 LnL7 mentioned this pull request Mar 16, 2017
@jbaum98
Copy link
Contributor

jbaum98 commented Mar 16, 2017

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1.severity: mass-darwin-rebuild 6.topic: darwin Running or building packages on Darwin
Projects
None yet
Development

Successfully merging this pull request may close these issues.

libnfc on macOS
5 participants