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

OS X "El Capitan": DYLD_LIBRARY_PATH not working unless SIP is turned off #913

Closed
frol opened this issue Jun 29, 2016 · 4 comments
Closed

Comments

@frol
Copy link
Member

frol commented Jun 29, 2016

I would like to just bring awareness of that DYLD_LIBRARY_PATH or DYLD_FALLBACK_LIBRARY_PATH are not working in OS X 10.11 "El Capitan" unless System Integrity Protection (SIP) is turned off.

While it is possible to disable SIP, it is certainly not the best way.

I'm quite new to OS X "features", so forgive me if I'm too late for the party.

@RSully
Copy link

RSully commented Jun 29, 2016

I haven't used conda on OSX yet (I plan to), but what problems does this cause?

@frol
Copy link
Member Author

frol commented Jun 29, 2016

@RSully DYLD_LIBRARY_PATH are usually used in recipes as a workaround when RPATH is not set correctly and package relies on conda prefix detection/patching, so it needs a help to find shared libraries installed into conda environment when executing tests, for example.

@dopplershift
Copy link
Member

To be clear, DYLD_LIBRARY_PATH and DYLD_FALLBACK_LIBRARY_PATH (and all other DYLD* environment variables) are only disabled by SIP for protected binaries--like those in /usr/bin. This means you can't pass them to things that use OSX's bash (like autotools), but they do work for passing to python (and even bash) so long as they aren't the system copies. This is one reason we use cmake to build libnetcdf.

@pelson
Copy link
Member

pelson commented Jul 8, 2016

Thanks for the info @frol. Are there issues we need to address, or is this a general "handy packager info" tidbit? If the latter, perhaps we should start pulling these together into a single document... interested in taking that on in https://github.com/conda-forge/conda-forge.github.io?

In the interests of keeping the issue tracker in some order, I'm going to go ahead and close the issue, but am definitely interested in using issues like this to help us build out our docs.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants