Python eseguibile non trovando libpython libreria condivisa

Question

Sto installando Python 2.7 su CentOS 5. ho costruito e installato Python come segue

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

Quando si tenta di eseguire/usr/local/bin/python, ho questa messaggio di errore

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

Quando eseguo ldd su///bin/python locale usr, ho

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) 

Come faccio dì a Python dove trovare libpython?

Answer 1

provare quanto segue:

LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/python 

Sostituire /usr/local/lib con la cartella in cui è stato installato libpython2.7.so.1.0 se non è in /usr/local/lib.

Se questo funziona e si desidera rendere permanenti le modifiche, si hanno due opzioni:

1. Aggiungi export LD_LIBRARY_PATH=/usr/local/lib al vostro .profile nella vostra home directory (questo funziona solo se si utilizza una shell che carica questo file quando viene avviata una nuova istanza di shell). Questa impostazione influenzerà solo il tuo utente.

2. Aggiungi /usr/local/lib a /etc/ld.so.conf ed eseguire ldconfig. Questa è ovviamente una configurazione a livello di sistema.

Answer 2

Ho avuto lo stesso problema e ho risolto in questo modo:

Se sai dove libpython risiede, ho supposto che sarebbe /usr/local/lib/libpython2.7.so.1.0 nel tuo caso, si può semplicemente creare un collegamento simbolico ad esso :

sudo ln -s /usr/local/lib/libpython2.7.so.1.0 /usr/lib/libpython2.7.so.1.0 

Quindi provare a eseguire ldd di nuovo e vedere se ha funzionato.

Answer 3

installa solo python-lib. (Python27-lib). Installa libpython2.7.so1.0. Non è necessario impostare manualmente nulla.

Answer 4

Ho installato utilizzando il comando:

./configure --prefix=/usr  \ 
      --enable-shared  \ 
      --with-system-expat \ 
      --with-system-ffi \ 
      --enable-unicode=ucs4 && 

make 

Ora, come utente root:

make install && 
chmod -v 755 /usr/lib/libpython2.7.so.1.0 

poi ho cercato di eseguire python e ottenuto l'errore:

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

Poi , Ho effettuato il logout da utente root e di nuovo ho provato a eseguire Python e ha funzionato correttamente.

Answer 5

Mettere il cappello becchino ...

Il modo migliore che ho trovato per affrontare questo è in fase di compilazione. Poiché tu sei il prefisso di una sola impostazione, potresti anche dire esplicitamente al file eseguibile dove trovare le sue librerie condivise.A differenza di OpenSSL e altri pacchetti software, Python non ti dà belle direttive di configurazione per gestire i percorsi alternativi di libreria (non tutti sono radice si sa ...) Nel caso più semplice tutto ciò che serve è il seguente:

./configure --enable-shared \ 
      --prefix=/usr/local \ 
      LDFLAGS="-Wl,--rpath=/usr/local/lib" 

o se si preferisce la versione non-linux:

./configure --enable-shared \ 
      --prefix=/usr/local \ 
      LDFLAGS="-R/usr/local/lib" 

il "rpath" flag dice pitone ha librerie di runtime di cui ha bisogno in quel particolare percorso. È possibile portare avanti questa idea per gestire le dipendenze installate in una posizione diversa rispetto alle posizioni di sistema standard. Ad esempio, sui miei sistemi dal momento che non ho accesso di root e la necessità di rendere quasi del tutto autosufficiente Python viene installato, la mia linea di configurazione è simile al seguente:

./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" 

In questo caso sto la compilazione delle librerie che Python utilizza (come ffi, readline, ecc.) in una directory extlib all'interno dell'albero stesso della directory python. In questo modo posso tar la directory python - $ {PYTHON_VERSION} e atterrarla ovunque e funzionerà "(a patto che non si verifichino conflitti libc o libm). Ciò aiuta anche quando si tenta di eseguire più versioni di Python nella stessa casella, poiché non è necessario continuare a modificare il proprio LD_LIBRARY_PATH o preoccuparsi di prelevare la versione errata della libreria Python.

Edit: Ho dimenticato di menzionare, la compilazione si lamenterà se non si imposta la variabile di ambiente PYTHONPATH a quello che si utilizza come il prefisso e non riescono a compilare alcuni moduli, per esempio, di estendere l'esempio precedente, impostare la PYTHONPATH al prefisso utilizzato nell'esempio precedente con export PYTHONPATH=/apps/python-${PYTHON_VERSION} ...

Answer 6

Ho installato Python 3.5 da Software Collections su CentOS 7 minimo. Tutto ha funzionato bene da solo, ma ho visto l'errore di libreria condivisa menzionato in questa domanda quando ho provato a fare funzionare un semplice 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 

volevo una soluzione permanente systemwide che funziona per tutti gli utenti, in modo che esclusi aggiungere istruzioni di esportazione a file .profile o .bashrc. Ho visto la soluzione here e ho realizzato che in realtà è menzionata in una delle risposte anche qui! In ogni caso, su CentOS 7, questi sono i passi:

vim /etc/ld.so.conf 

che sulla mia macchina ha appena avuto:

così ho creato un nuovo file:

vim /etc/ld.so.conf.d/rh-python35.conf 

e ha aggiunto:

/opt/rh/rh-python35/root/usr/lib64/ 

Dopo un riavvio, il seguente ing passo non era necessario, ma per ricostruire manualmente la cache:

sudo ldconfig 

Questo è tutto, gli script funzionano bene!

Questa era una soluzione temporanea, che non ha funzionato dopo il riavvio:

sudo ldconfig /opt/rh/rh-python35/root/usr/lib64/ -v 

L'opzione -v (verbose) era solo per vedere cosa stava succedendo. Ho visto che lo ha fatto: /opt/rh/rh-python35/root/usr/lib64: libpython3.so.rh-python35 -> libpython3.so.rh-python35 libpython3.5m.so.rh-python35- 1.0 -> libpython3.5m.so.rh-python35-1.0

Questo errore particolare è andato via. Per inciso, ho dovuto chmod all'utente di apache per sbarazzarsi di un errore di autorizzazione dopo.

Nota che ho utilizzato per trovare la directory per la libreria. Si potrebbe anche fare:

sudo yum install mlocate 
sudo updatedb 
locate libpython3.5m.so.rh-python35-1.0 

Che sul mio VM restituisce:

/opt/rh/rh-python35/root/usr/lib64/libpython3.5m.so.rh-python35-1.0 

che è il percorso che ho bisogno di dare a ldconfig, come indicato sopra.

Answer 7

Questo ha funzionato per me ...

$ sudo apt-get install python2.7-dev