Alternative pour le DYLD_LIBRARY_PATH-trick depuis Mac OS 10.11 El Capitan avec protection du système d'intégrité

Question

Voici ce que j'ai:

• Mac OS 10.11 El Capitan
• python 2.7.12, installé depuis python. org sous /Library/Frameworks/Python.framework/
• PyCharm 2016.2.3
• VTK 7.1.0

Voici ce que je fais:

• Construire un module python local. Dans mon cas, c'est vtk. Pour un résumé, voir l'appel CMake avec lequel je configure vtk. Installez le paquet python à un emplacement où Python peut le trouver. Dans mon cas, c'est /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages Notez que je suis requis d'étendre le DYLD_LIBRARY_PATH par l'emplacement où résident les bibliothèques: /opt/dev/versions/vtk/vtk-7.1.0-shared/lib/. Si je démarre Python à partir du terminal, je peux importer vtk avec succès.

  import vtk 
  v = vtk.vtkVersion() 
  print v.GetVTKVersion() 
  

• Si je tente d'importer VTK dans la console python de PyCharm, je reçois l'erreur suivante:

  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 "<ipython-input-2-b7e11aadda62>", line 1, in <module> 
      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 <module> 
      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 <module> 
      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 
  

Maintenant, je comprends que le problème est causé par le System Integrity Protection (SIP) qui a été introduit à El Capitan. L'un des effets est que les processus enfants n'ont que restricted access pour d'autres ressources, et très probablement, PyCharm exécute python en tant que processus séparé.

Je comprends également que python ne peut pas importer vtk car il ne trouve pas les dylibs auxquels le module python est lié. Je peux vérifier cela de deux façons:

• Le DYLD_LIBRARY_PATH est vide. Ceci est dû au fait que python s'exécute en tant que processus fils dans PyCharm: os.getenv('DYLD_LIBRARY_PATH') renvoie None.
• Lorsque je copie toutes les bibliothèques de /opt/dev/versions/vtk/vtk-7.1.0-shared/lib/ dans le répertoire de travail actuel, je peux importer le module

Maintenant, la question: Apparemment, DYLD_LIBRARY_PATH ne peut pas être utilisé chez l'enfant-processus et par conséquent ne doivent pas être utilisés plus du tout depuis El Capitan. Alors, comment remplacer correctement ce "lien hack" qui fonctionnait parfaitement bien avant MacOS 10.11.? Est-il un moyen d'utiliser encore DYLD_LIBRARY_PATH?

La désactivation de SIP n'est pas une option. Apparemment, cela aide à copier les dylibs dans le répertoire de travail actuel, mais ce n'est pas faisable pour moi. Placer les libs dans l'emplacement du site-package (de vtk) n'aide cependant pas.Je suis à peu près certain que beaucoup de gens se sont appuyés sur le DYLD_LIBRARY_PATH -hack et se battent maintenant avec les conséquences de SIP - c'est pourquoi j'ai pensé que la communauté pourrait bénéficier de cette question assez longue.

Answer 1

Après un long combat, j'ai été capable de résoudre le dernier morceau de mon problème.

En définissant une valeur fixe pour le fichier RPATH Run-Path dependent Libraries des fichiers binaires installés, mes problèmes de liaison ont disparu.

Il existe différentes possibilités pour y parvenir. Je suppose qu'une option est d'utiliser install_name_tool. Pour moi, le plus simple était de construire vtk avec les drapeaux CMake appropriés. Voici mon appel mis à jour cmake, où CMAKE_MACOSX_RPATH et CMAKE_INSTALL_RPATH font la différence:

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" 

Lire here plus sur la gestion des rpath de CMake. Notez que otool -L vtkCommonCorePython.so (pour un exemple) écrit toujours @rpath dans la sortie, mais la valeur est toujours fixe.

@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)