Alternative for the DYLD_LIBRARY_PATH-trick since Mac OS 10.11 El Capitan with System Integrity Protection
<p><strong>Here is what I have:</strong></p>

<ul>
<li>Mac OS 10.11 El Capitan</li>
<li>python 2.7.12, installed from python.org under <code>/Library/Frameworks/Python.framework/</code></li>
<li>PyCharm 2016.2.3</li>
<li>vtk 7.1.0</li>
</ul>

<p><strong>Here is what I do:</strong></p>

<ul>
<li><p>Build a python module locally. In my case, this is <a href="http://www.vtk.org/" rel="nofollow">vtk</a>. For a summary, see the CMake call with which I configure vtk. </p>

<pre><code>cmake -G Ninja .. -DCMAKE_BUILD_TYPE=Release -DVTK_WRAP_PYTHON=ON -DBUILD_EXAMPLES=OFF -DBUILD_SHARED_LIBS=ON -DBUILD_TESTING=OFF -DCMAKE_INSTALL_PREFIX="/opt/dev/versions/vtk/vtk-7.1.0-shared" -DPYTHON_INCLUDE_DIR="/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/" -DPYTHON_LIBRARY="/Library/Frameworks/Python.framework/Versions/2.7/lib/libpython2.7.dylib"
</code></pre></li>
<li><p>Install the python package in a location where python can find it. In my case, this is <code>/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages</code>
Note that I am required to extend the <code>DYLD_LIBRARY_PATH</code> by the location where the libs reside: <code>/opt/dev/versions/vtk/vtk-7.1.0-shared/lib/</code>. </p></li>
<li><p>If I start python from the terminal, I can import vtk successfully.</p>

<pre><code>import vtk
v = vtk.vtkVersion()
print v.GetVTKVersion()
</code></pre></li>
<li><p>If I try to import vtk in PyCharm's python console, I get the following error:</p>

<pre><code>Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/IPython/core/interactiveshell.py", line 2881, in run_code
    exec(code_obj, self.user_global_ns, self.user_ns)
  File "&lt;ipython-input-2-b7e11aadda62&gt;", line 1, in &lt;module&gt;
    import vtk
  File "/Applications/PyCharm.app/Contents/helpers/pydev/_pydev_bundle/pydev_import_hook.py", line 21, in do_import
    module = self._system_import(name, *args, **kwargs)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/vtk/__init__.py", line 41, in &lt;module&gt;
    from .vtkCommonCore import *
  File "/Applications/PyCharm.app/Contents/helpers/pydev/_pydev_bundle/pydev_import_hook.py", line 21, in do_import
    module = self._system_import(name, *args, **kwargs)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/vtk/vtkCommonCore.py", line 9, in &lt;module&gt;
    from vtkCommonCorePython import *
  File "/Applications/PyCharm.app/Contents/helpers/pydev/_pydev_bundle/pydev_import_hook.py", line 21, in do_import
    module = self._system_import(name, *args, **kwargs)
ImportError: No module named vtkCommonCorePython
</code></pre></li>
</ul>

<p>By now, I understand that the problem is caused by the <a href="https://en.wikipedia.org/wiki/System_Integrity_Protection" rel="nofollow">System Integrity Protection</a> (SIP) that has been introduced in El Capitan. One of the effects is that child processes only have <a href="https://developer.apple.com/library/content/documentation/Security/Conceptual/System_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.html" rel="nofollow">restricted access</a> to other resources, and most likely, PyCharm executes python as separate process.</p>

<p>I also understand that python cannot import vtk because it cannot find the dylibs which the python module links to. I can verify this in two ways:</p>

<ul>
<li>The <code>DYLD_LIBRARY_PATH</code> is empty. This is because python runs as a child process in PyCharm: <code>os.getenv('DYLD_LIBRARY_PATH')</code> returns <code>None</code>.</li>
<li>When I copy all the libraries from <code>/opt/dev/versions/vtk/vtk-7.1.0-shared/lib/</code> to the current working directory, I can import the module</li>
</ul>

<p><strong>Now the question</strong>: Apparently, <code>DYLD_LIBRARY_PATH</code> cannot be used in child-processes and hence should not be used anymore at all since El Capitan. So, how to properly replace this "linkage hack" that worked perfectly well before MacOS 10.11.? Is there a way to still use <code>DYLD_LIBRARY_PATH</code>? </p>

<p>Disabling SIP is not an option. Apparently, it helps to copy the dylibs into the current working directory, but this is not feasible for me. Placing the libs in the site-package location (of vtk) doesn't help however.</p>

<p>I'm pretty sure that many people have been relying on the <code>DYLD_LIBRARY_PATH</code>-hack and now struggle with the consequences of SIP - that's why I thought that the community might benefit from this quite lengthy question.</p>

<p>After a long struggle, I was able to solve the last bit of my problem.</p>

<p>By setting a <strong>fixed value for the RPATH <a href="https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/RunpathDependentLibraries.html" rel="nofollow">Run-Path dependent Libraries</a> of the installed binaries</strong>, my linking problems are gone. </p>

<p>There are different possibilities to achieve this. I guess one option is to use <code>install_name_tool</code>. For me, the easiest was to build vtk with appropriate CMake flags. Here my updated call to <code>cmake</code>, where <code>CMAKE_MACOSX_RPATH</code> and <code>CMAKE_INSTALL_RPATH</code> make the difference:</p>

<pre><code>    cmake -G Ninja .. -DCMAKE_BUILD_TYPE=Release \
              -DVTK_WRAP_PYTHON=ON \
              -DBUILD_EXAMPLES=OFF \
              -DBUILD_SHARED_LIBS=ON \
              -DBUILD_TESTING=OFF \
              -DCMAKE_INSTALL_PREFIX="/opt/dev/versions/vtk/vtk-7.1.0-shared" \
              -DCMAKE_MACOSX_RPATH=ON \
              -DCMAKE_INSTALL_RPATH="/opt/dev/versions/vtk/vtk-7.1.0-shared/lib" \
              -DPYTHON_INCLUDE_DIR="/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/" \
              -DPYTHON_LIBRARY="/Library/Frameworks/Python.framework/Versions/2.7/lib/libpython2.7.dylib"
</code></pre>

<p>Read <a href="https://cmake.org/Wiki/CMake_RPATH_handling#Always_full_RPATH" rel="nofollow">here</a> more about CMake's rpath handling. Note that <code>otool -L vtkCommonCorePython.so</code> (for an example) will still write <code>@rpath</code> in the output, but the value still is fixed.</p>

<pre><code>@rpath/libvtkCommonCorePython27D-7.1.1.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libvtkWrappingPython27Core-7.1.1.dylib (compatibility version 0.0.0, current version 0.0.0)
/Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.0)
@rpath/libvtksys-7.1.1.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libvtkCommonCore-7.1.1.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
</code></pre>

python osx vtk dyld