Python exécutable ne pas trouver libpython bibliothèque partagée

Je suis d'installer Python 2.7 sur CentOS 5. J'ai construit et installé Python comme suit

./configure --enable-shared --prefix=/usr/local
make
make install

Lorsque j'essaie d'exécuter le fichier /usr/local/bin/python, j'obtiens ce message d'erreur

/usr/local/bin/python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory

Quand je lance la commande ldd sur /usr/local/bin/python, je reçois

ldd /usr/local/bin/python
    libpython2.7.so.1.0 => not found
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00000030e9a00000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00000030e9200000)
    libutil.so.1 => /lib64/libutil.so.1 (0x00000030fa200000)
    libm.so.6 => /lib64/libm.so.6 (0x00000030e9600000)
    libc.so.6 => /lib64/libc.so.6 (0x00000030e8e00000)
    /lib64/ld-linux-x86-64.so.2 (0x00000030e8a00000)

Comment dois-je dire à Python où trouver libpython?

InformationsquelleAutor sans | 2011-10-24

python

193

Essayez ce qui suit:
```
LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/python
```
Remplacer /usr/local/lib avec le dossier où vous avez installé libpython2.7.so.1.0 si elle n'est pas dans /usr/local/lib.

Si cela fonctionne et si vous voulez rendre les modifications permanentes, vous avez deux options:
1. Ajouter export LD_LIBRARY_PATH=/usr/local/lib à votre .profile dans votre répertoire home (cela ne fonctionne que si vous utilisez un shell qui permet de charger ce fichier lorsqu'une nouvelle instance du shell est lancé). Cela affectera votre utilisateur uniquement.
2. Ajouter /usr/local/lib à /etc/ld.so.conf et exécuter ldconfig. C'est un système à l'échelle de réglage de cours.
- Est-il possible de l'exporter afin qu'il travaille avec eclipse? Je l'ai ajouté à mes .profil de l'Éclipse n'est pas en mesure de lancer gdb. (Remarque: l'Ajout à la ld.donc.conf fonctionne cependant)
- donc j'ai vérifié les variables d'environnement eclipse est en cours d'exécution et il a le bon LD_LIBRARY_PATH. Je crois que quand il lance GDB, il n'utilise pas n'importe quel environnement et, par conséquent, ne pas être des variables d'environnement! Réglage de la libpython dans la configuration de débogage n'a pas aider non plus, puisqu'il n'est que pour quand gdb charge réellement (mais j'ai besoin de la lib pour gdb lui-même à charger)
- Vous pouvez déboguer l'application avec succès lorsque vous exécutez gdb à partir de la ligne de commande et LD_LIBRARY_PATH est configuré correctement dans le terminal? Si non, vous devrez probablement configurer LD_LIBRARY_PATH dans votre .gdbinit fichier. Voir cette réponse pour plus d'info: stackoverflow.com/a/7041845/156771
- J'ai besoin de la LD_LIBRARY_PATH pour lancer gdb (python libs) pas pour le débogage de mon application. Jusqu'à présent, j'ai seulement réussi à le résoudre par la mise en ldconfig. Je peux déboguer l'application via l'interface CLI parce qu'il va décrocher le LD_LIBRARY_PATH de mon ZSHRC fichier.
- Juste une remarque pour ceux qui cherchent à ceci: C'est juste "/usr/local/lib", et non pas un départ "comprennent" que l'original "inclure les ld.donc.conf.d/*.conf".
- Pour quelqu'un qui n'est pas en mesure de définir le LD_LIBRARY_PATH pour apache cela aidera serverfault.com/questions/424997/...
- Merci une tonne pour que timss. Qui m'a vraiment aidé
- "LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/python" donne: "bash: /usr/local/bin/python: No such file or directory". Je suis sur Ubuntu 14.04.
- La question initiale est d'environ un Python instance qui est installé dans /usr/local, j'ai donc utilisé que dans ma réponse. Si votre Python est ailleurs, ajuster les chemins d'accès en conséquence.
- L'ajout de export LD_LIBRARY_PATH=/usr/local/lib à /etc/profile et de l'approvisionnement (source /etc/profile) le profil résolu mon cas. Je vous remercie beaucoup.
- L'exécution de ldconfig affiche le message d'erreur ldconfig: /usr/local/lib/libpython2.7.donc.1.0 n'est pas un fichier ELF - il a la mauvaise magie octets au début de l'étape 2
- Je pense qu'une 3ème possibilité de faire des changements permanents " est d'inclure les chemins d'accès que vous définissez dans LD_LIBRARY_PATH dans le cadre de la LDFLAGS lors de la configuration pour make
InformationsquelleAutor Tamás
71

Mettre sur mon fossoyeur chapeau...

Le meilleur moyen que j'ai trouvé à l'adresse c'est au moment de la compilation. Puisque vous êtes le seul réglage préfixe de toute façon, pourrait tout aussi bien dire l'exécutable explicitement où trouver ses bibliothèques partagées. Contrairement à d'OpenSSL et autres logiciels, Python ne vous donne pas agréable de configurer des directives pour gérer suppléant de la bibliothèque des chemins (pas tout le monde est à la racine, vous savez...) Dans le cas le plus simple de tous vous avez besoin est le suivant:
```
./configure --enable-shared \
            --prefix=/usr/local \
            LDFLAGS="-Wl,--rpath=/usr/local/lib"
```
Ou si vous préférez la non-linux version:
```
./configure --enable-shared \
            --prefix=/usr/local \
            LDFLAGS="-R/usr/local/lib"
```
La "rpath" drapeau indique à python qu'il a des bibliothèques d'exécution dont il a besoin dans cette voie-là. Vous pouvez prendre cette idée pour gérer les dépendances installé à un emplacement différent de la norme emplacements du système. Par exemple, sur mes systèmes puisque je n'ai pas accès à la racine et le besoin de faire presque complètement autonome Python installe, ma ligne de configuration ressemble à ceci:
```
./configure --enable-shared \
            --with-system-ffi \
            --with-system-expat \
            --enable-unicode=ucs4 \
            --prefix=/apps/python-${PYTHON_VERSION} \
            LDFLAGS="-L/apps/python-${PYTHON_VERSION}/extlib/lib -Wl,--rpath=/apps/python-${PYTHON_VERSION}/lib -Wl,--rpath=/apps/python-${PYTHON_VERSION}/extlib/lib" \
            CPPFLAGS="-I/apps/python-${PYTHON_VERSION}/extlib/include"
```
Dans ce cas, je suis de compiler les bibliothèques que python utilise (comme ffi, readline, etc) dans un extlib répertoire dans le répertoire python arbre lui-même. De cette façon, je peux goudron python-${PYTHON_VERSION} répertoire et de la terre n'importe où et il va "travailler" (à condition que vous ne courez pas dans libc ou libm conflits). Cela aide aussi quand vous essayez d'exécuter plusieurs versions de Python sur la même zone, comme vous n'avez pas besoin de changer votre LD_LIBRARY_PATH ou des inquiétudes au sujet de la cueillette de la mauvaise version de la bibliothèque Python.

Edit: j'ai Oublié de mentionner, la compilation va se plaindre si vous ne définissez pas la PYTHONPATH variable d'environnement pour ce que vous utilisez comme votre préfixe et ne parviennent pas à compiler des modules, par exemple, d'étendre l'exemple ci-dessus, réglez le PYTHONPATH le préfixe utilisé dans l'exemple ci-dessus avec export PYTHONPATH=/apps/python-${PYTHON_VERSION}...
- Ce qui m'a sauvé beaucoup de temps, merci!
- // , Cela ressemble à ce que je cherche. Où puis-je en savoir plus sur les façons de "tar python-répertoire de la version et de la terre n'importe où et il va "travailler" (à condition de ne pas exécuter dans la libc ou libm conflits)"? Pensez-vous que cela vaut la peine de faire un distinct stackoverflow.com question de sortir de cette situation?
- // , Aussi, comment doit-on définir $PYTHON_VERSION?
- // , J'ai mis $PYTHON_VERSION après la configuration. Même avec la $PYTHON_VERSION ensemble, toutefois, le compilateur se plaint Python build finished successfully! The necessary bits to build these optional modules were not found: _bz2 _curses _curses_panel _gdbm _lzma _sqlite3 _tkinter readline
- // , Ne nécessite aucune modification à la make de commande et d'autres commandes d'installation?
- // , Également, que faire si votre Python besoins de l'application du système de paquets comme yum install python-lxml?
- dans le cas des disparus bz2, les malédictions, gdbm, lzma, etc vous devez compiler chacun de ces premières avec un préfixe de /apps/python-${PYTHON_VERSION}/extlib pour assurer leurs bibliothèques et en-têtes sont dans le bon emplacement pour le Python rendre le processus pour trouver. À niveau du système de paquets, vous seriez probablement coincé en s'appuyant sur l'utilisateur root pour installer ces pour vous à l'avance. Ou trouver une alternative qui peut être compilé et a atterri dans la extlib
- votre cas plus simple cammand m'a aidé à！！！Merci beaucoup !
- Lors de la compilation de pyhton3.6, j'ai dû mettre à la fois le -Wl,--rpath= et -L pièces dans le LDFLAGS. -Wl,--rpath= ne suffit pas. Je serais intéressé de savoir quand et pourquoi -L pourrait être nécessaire.
- vient vers le bas si vous avez toutes les bibliothèques dont vous avez besoin sur le système hôte déjà dans les chemins d'accès par défaut ou si vous avez plus de la bibliothèque des chemins, vous devez inclure
InformationsquelleAutor Foosh
18

J'ai eu le même problème et je l'ai résolu de cette façon:

Si vous savez où libpython réside à l', j'ai supposé qu'il serait /usr/local/lib/libpython2.7.so.1.0 dans votre cas, il vous suffit de créer un lien symbolique vers:
```
sudo ln -s /usr/local/lib/libpython2.7.so.1.0 /usr/lib/libpython2.7.so.1.0
```
Puis essayez d'exécuter ldd à nouveau et de voir si cela a fonctionné.
- a fonctionné pour moi après avoir fait un "ldconfig'
InformationsquelleAutor Omer Dagan
5

J'ai installé Python 3.5 par Logiciel De Collections sur CentOS 7 minime. Tout a bien fonctionné sur son propre, mais j'ai vu l'erreur de bibliothèque partagée mentionnées dans cet question, quand j'ai essayé de courir un simple script CGI:
```
tail /var/log/httpd/error_log
AH01215: /opt/rh/rh-python35/root/usr/bin/python: error while loading shared libraries: libpython3.5m.so.rh-python35-1.0: cannot open shared object file: No such file or directory
```
Je voulais un système permanent de la solution qui fonctionne pour tous les utilisateurs, de sorte que les exclus de l'ajout d'exportation des déclarations .de profil ou de .bashrc fichiers. Il y a une solution en ligne, basé sur le Les solutions Red Hat page. Merci pour le commentaire qu'il souligne:
```
echo 'source scl_source enable rh-python35' | sudo tee --append /etc/profile.d/python35.sh
```
Après un redémarrage, c'est du tout bon sur la coque, mais parfois mon serveur web se plaint toujours. Il y a une autre approche qui a toujours travaillé pour à la fois la coquille et le serveur, et est plus générique. J'ai vu la solution ici puis réaliser qu'il est effectivement mentionné dans l'une des réponses ici! De toute façon, sur CentOS 7, voici les étapes:
```
 vim /etc/ld.so.conf
```
Qui sur ma machine juste eu:
```
include ld.so.conf.d/*.conf
```
J'ai donc créé un nouveau fichier:
```
vim /etc/ld.so.conf.d/rh-python35.conf
```
Et a ajouté:
```
/opt/rh/rh-python35/root/usr/lib64/
```
Et reconstruire manuellement le cache:
```
sudo ldconfig
```
Que c'est, scripts, beau travail!

C'était une solution temporaire, qui n'a pas fonctionné lors des redémarrages:
```
sudo ldconfig /opt/rh/rh-python35/root/usr/lib64/ -v
```
L'option-v (verbose) option était juste pour voir ce qui se passait. J'ai vu qu'il a fait:
/opt/rh/rh-python35/root/usr/lib64:
libpython3.donc.rh-python35 -> libpython3.donc.rh-python35
libpython3.5m.donc.rh-python35-1.0 -> libpython3.5m.donc.rh-python35-1.0

Cette erreur a disparu. D'ailleurs, j'ai dû chown à l'utilisateur d'apache pour se débarrasser d'une erreur d'autorisation après que.

Notez que j'ai utilisé trouver pour localiser le répertoire de la bibliothèque. Vous pouvez aussi faire:
```
sudo yum install mlocate
sudo updatedb
locate libpython3.5m.so.rh-python35-1.0
```
Qui sur ma VM retourne:
```
/opt/rh/rh-python35/root/usr/lib64/libpython3.5m.so.rh-python35-1.0
```
Qui est le chemin que j'ai besoin de donner à ldconfig, comme indiqué ci-dessus.
- Vous pourriez avoir vous-même sauvé quelques difficultés en allant dans /etc/profile.d et la création d'un fichier avec ce qui suit: #!/bin/bash et source scl_source enable rh-python35 en elle. access.redhat.com/solutions/527703
- cela devrait être une réponse! Essayé sur une autre machine, bien meilleure approche.
- je cherchais la réponse est correcte, il a fallu près de 3 jours pour moi à résoudre ce problème. Merci @Nagev pour les efforts.
InformationsquelleAutor Nagev
1

Cela a fonctionné pour moi...
```
$ sudo apt-get install python2.7-dev
```
- Salut, ce n'est pas la bonne solution, parce que, après cela, votre version personnalisée python binaire est l'aide de l' .donc, à partir de celui que vous avez installé à partir d'apt-get. Cela peut entraîner des problèmes alors qu'ils ont la même version, ou si vous avez modifié le code source python, il ne sera pas faire des efforts.
InformationsquelleAutor Kyle Anderson
1

Sur Solaris 11

Utilisation LD_LIBRARY_PATH_64 pour résoudre un lien symbolique pour les libs python.

Dans mon cas pour python3.6 LD_LIBRARY_PATH n'ai pas de travail mais LD_LIBRARY_PATH_64 fait.

Espère que cette aide.

Ce qui concerne

InformationsquelleAutor basy
0

J'ai installé à l'aide de la commande:
```
./configure --prefix=/usr       \
            --enable-shared     \
            --with-system-expat \
            --with-system-ffi   \
            --enable-unicode=ucs4 &&

make
```
Maintenant, en tant qu'utilisateur root:
```
make install &&
chmod -v 755 /usr/lib/libpython2.7.so.1.0
```
Puis j'ai essayé d'exécuter du python et obtenu l'erreur:

/usr/local/bin/python: error while loading shared libraries: libpython2.7.donc.1.0: ne peut ouvrir le fichier objet partagé: Aucun fichier ou répertoire de

Puis, je me suis déconnecté de la racine de l'utilisateur et de nouveau essayé d'exécuter du Python et cela a fonctionné avec succès.

InformationsquelleAutor Pankaj
0

Tout ce qu'il faut c'est l'installation de libpython [3 ou 2] dev fichiers d'installation.

InformationsquelleAutor
-1

il suffit d'installer python-lib. (python27-lib). Il va installer libpython2.7.rs1.0. Nous n'avons pas besoin de régler manuellement quoi que ce soit.
- / / Et si vous êtes sur, disons, CEntOS 6.3? Cela ne fonctionne pas, là, et habituellement, les gens sont de compiler Python pour traiter une affaire où le système de Python est un drôle de version, cassé, peu fiables, ou de quelque autre désir de ne pas toucher l'ensemble du système.
InformationsquelleAutor chintan-p-bhatt

Vous devez vous connecter pour publier un commentaire.