J'ai vu plusieurs messages qui mentionnaient la même erreur, mais il n'a pas été utile de rechercher et d'essayer de trouver les réponses. Je me demandais si quelqu'un pourrait regarder cela et voir si quelque chose sortait?
Je construis une extension Python pour une application CPP, et il n'y a pas d'erreur lors de la compilation et de la compilation. Cependant, lorsque j'importe le module, le message d'erreur mentionné dans le titre apparaît. D'autres réponses de stackoverflow ont affirmé que cela était dû au fait d'être lié à une bibliothèque lors de la compilation et d'utiliser un interpréteur différent. Autant que je sache, j'utilise le même interpréteur Python. Je vais maintenant décrire pourquoi je pense utiliser le même Python dans le processus de liaison et pour l'interprète.
Ceci est la commande que j'utilise pour construire l'extension Python
$ gcc -shared helicsPYTHON_wrap.c $(python-config3 --includes) -I/path/to/helics-0.9/includes -L/path/to/helics-0.9/lib -lhelicsSharedLib -L$(python3-config --prefix)/lib -lpython3.6m -o _helics.so
$ which python3-config
/Users/$USER/miniconda3/bin/python3-config
$ python3-config --prefix
/Users/$USER/miniconda3
Si j'essaie d'importer le fichier python qui importe la bibliothèque partagée, l'erreur fatale est renvoyée. Si j'utilise otool -L
sur la bibliothèque partagée, j'obtiens le suivant. C'est ce que j'espère obtenir.
$ otool -L _helics.so
_helics.so:
@rpath/libhelicsSharedLib.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libpython3.6m.dylib (compatibility version 3.6.0, current version 3.6.0)
/usr/local/opt/zeromq/lib/libzmq.5.dylib (compatibility version 7.0.0, current version 7.3.0)
libboost_program_options.dylib (compatibility version 0.0.0, current version 0.0.0)
libboost_filesystem.dylib (compatibility version 0.0.0, current version 0.0.0)
libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0)
libboost_date_time.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/opt/gcc/lib/gcc/7/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.24.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)
/usr/local/lib/gcc/7/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
J'ai aussi essayé install_name_tool
pour ajouter le chemin complet du fichier libpython3.6m.dylib.
$ install_name_tool -change @rpath/libpython3.6m.dylib /Users/$USER/miniconda3/envs/py3/lib/libpython3.6m.dylib _helics.so
J'ai toujours la même erreur fatale. Mon hypothèse est que mon installation de Mac System Python 2.7 a un effet sur ce processus à un moment donné. Je suis incapable d'identifier où cependant.
Y a-t-il un moyen d'ajouter plus d'instructions de débogage pour savoir pourquoi une erreur Fatal Python se produit. Actuellement, le message d'erreur est très court.
$ python helics.py
Fatal Python error: PyThreadState_Get: no current thread
[1] 64481 abort python helics.py
Curieusement, si j'utilise un environnement Conda et Python 2.7, je peux charger l'extension correctement! C'est pourquoi je pense que lorsque j'utilise Python 3.6, il récupère en quelque sorte quelque chose dans l'installation par défaut du système Mac et fonctionne correctement. Je prends la même chose lorsque j'utilise l'environnement python conda 2.7, mais comme ils sont tous deux Python 2.7 (bien que conda soit 2.7.14 et python système, 2.7.10), il semble fonctionner. Ceci est la sortie otool -L
lorsque j'utilise un environnement conda.
$ otool -L _helics.so
_helics.so:
@rpath/libhelicsSharedLib.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libpython2.7.dylib (compatibility version 2.7.0, current version 2.7.0)
/usr/local/opt/zeromq/lib/libzmq.5.dylib (compatibility version 7.0.0, current version 7.3.0)
libboost_program_options.dylib (compatibility version 0.0.0, current version 0.0.0)
libboost_filesystem.dylib (compatibility version 0.0.0, current version 0.0.0)
libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0)
libboost_date_time.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/opt/gcc/lib/gcc/7/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.24.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.60.2)
/usr/local/lib/gcc/7/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
Les questions que je me pose sont 1) comment obtenir plus d’informations de débogage à partir de l’erreur de Python. J'ai essayé python -vvv
et cela ne me donne pas assez d'informations. J'ai essayé d'utiliser gdb mais cela ne m'a également donné aucune information. Je crois que cela nécessite de recompiler Python lui-même en utilisant des symboles de débogage. 2) Avez-vous des recommandations sur la façon de résoudre ce problème ou de déboguer davantage?
De plus, je ne suis pas sûr qu'il s'agisse d'informations utiles, mais je peux utiliser ctypes et charger la bibliothèque partagée après l'avoir créée. Je n'arrive pas à l'importer en tant que module python.
Ceci est la version originale si on est intéressé - https://github.com/GMLC-TDC/HELICS-src/issues/59
Edit: J'ai essayé ceci en utilisant zsh et bash, et j'ai toujours la même erreur. J'ai également essayé de définir le export PATH="/Users/$USER/miniconda3/bin:/Users/$USER/miniconda3/lib"
suivant temporairement dans le shell et de l'exécuter, et j'obtiens ENCORE la même erreur. Cela aurait dû exclure mon système Mac System Python 2.7.10, donc je ne sais vraiment pas ce qui se passe.
Modifier à nouveau: j'ai également essayé de réinstaller miniconda avec Python2. Et si j'utilise Python2, tout fonctionne bien. Je ne peux pas utiliser Python3 avec Miniconda. Curieusement, si j'utilise homebrew et installe Python3, cela semble fonctionner correctement.
Editer à nouveau: C'est peut-être un problème avec High Sierra. Je n'ai actuellement pas accès à un autre Mac, mais je suis sur le dernier système d'exploitation qui dispose de SIP. Je ne suis pas sûr si cela cause ce problème. De plus, j'ai essayé d'utiliser Anaconda3 et je n'ai pas eu de chance.
Modifier à nouveau: cela ne semble pas être lié au système d'exploitation. Je peux exécuter ceci avec succès sur un autre ordinateur avec High Sierra.
Modifier à nouveau: j'ai testé cela sur d'autres installations d'OS fraîches, et elles ne fonctionnent pas. Mais ils travaillent sur deux de mes machines. Existe-t-il d'autres outils vous indiquant la dépendance nécessaire d'une bibliothèque ou à quel endroit Python génère une erreur fatale? Ma meilleure hypothèse pour le moment est que j’ai déjà installé quelque chose sur mes autres machines qui permet à cela de fonctionner. Je dois identifier ce que c'était et m'assurer que je peux le documenter.
Edit again: J'ai ajouté un Gist de la sortie de la version de Python que j'utilise.
Modifier à nouveau: j'ai ajouté les balises pour miniconda et anaconda car je ne rencontre pas ce problème lorsque j'utilise l'homebrew python3, mais uniquement lorsque j'utilise miniconda3 ou anaconda2 dans un environnement python3. Cela semble toujours fonctionner avec Python2, que ce soit un homebrew, un anaconda ou un miniconda.
Editer à nouveau:
Voici les étapes à suivre si quelqu'un d'autre souhaite se répliquer sur sa machine.
git clone https://github.com/GMLC-TDC/HELICS-src
mkdir build-osx
brew install boost
brew install cmake
brew install swig
cmake -DBUILD_PYTHON=ON -DPYTHON_LIBRARY=$(python3-config --prefix)/lib/libpython3.6m.dylib -DPYTHON_INCLUDE_DIR=$(python3-config --prefix)/include/python3.6m/ ..
make
cd ./swig/python/
python helics.py # Error
J'ai pu résoudre ce problème en modifiant le CMakeLists.txt
afin qu'il utilise -undefined dynamic_lookup
comme suggéré dans cette réponse . Par exemple. du fichier CMakeLists.txt est ici . Et la raison pour laquelle j’obtenais des résultats différents sur différentes machines était parce que l’un de mes macs avait Python 3.6.1 mais les autres Python> = 3.6.2
Vous avez Python 3.6, de homebrew ... Bien que votre module, tout en construisant référencé Python 2.7, fourni par le système. Ici est le même problème décrit. Dans l'un des commentaires - python3.6-config --ldflags
affichera LDFLAGS
à utiliser dans votre Makefile.
Assurez-vous que le répertoire lib du framework python actif se trouve dans le chemin de recherche de l'éditeur de liens. J'espère que cela fonctionnera.