L'eseguibile Python non trova la libreria condivisa libpython

Sto installando Python 2.7 su CentOS 5. Ho creato e installato Python come segue

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

Quando provo a eseguire / usr / local / bin / python, ricevo questo 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 / usr / local / bin / python, ottengo

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 a dire a Python dove trovare libpython?

Prova quanto segue:

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

Sostituisci /usr/local/libcon la cartella in cui hai installato libpython2.7.so.1.0se non è presente /usr/local/lib.

Se funziona e vuoi rendere permanenti le modifiche, hai due opzioni:

1. Aggiungi export LD_LIBRARY_PATH=/usr/local/liballa tua .profilenella tua home directory (funziona solo se stai usando una shell che carica questo file all'avvio di una nuova istanza della shell). Questa impostazione interesserà solo il tuo utente.

2. Aggiungi /usr/local/liba /etc/ld.so.confed esegui ldconfig. Questa è ovviamente un'impostazione a livello di sistema.

Indossa il mio cappello da becchino ...

Il modo migliore che ho trovato per risolvere questo problema è al momento della compilazione. Dato che sei l'unico prefisso di impostazione, potresti anche dire esplicitamente all'eseguibile dove trovare le sue librerie condivise. A differenza di OpenSSL e di altri pacchetti software, Python non fornisce istruzioni di configurazione per gestire percorsi di libreria alternativi (non tutti sono root che conosci ...) Nel caso più semplice tutto ciò che serve è il seguente:

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

O se preferisci la versione non Linux:

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

Il rpathflag " " indica a Python che ha librerie di runtime necessarie in quel particolare percorso. È possibile portare ulteriormente questa idea per gestire le dipendenze installate in una posizione diversa rispetto alle posizioni di sistema standard. Ad esempio, sui miei sistemi poiché non ho accesso come root e devo effettuare installazioni Python quasi completamente autonome, la mia linea di configurazione è simile alla 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 compilazione dei librerie che usi Python (come ffi, readline, ecc) in una extlibdirectory all'interno della directory pitone stesso. In questo modo posso tarare la directory python - $ {PYTHON_VERSION} e farla atterrare ovunque e "funzionerà" (a patto che non ci si imbatta libco sia in libmconflitto). Questo aiuta anche quando si tenta di eseguire più versioni di Python nella stessa casella, poiché non è necessario continuare a modificare LD_LIBRARY_PATHo preoccuparsi di prendere la versione errata della libreria Python.

Modifica: HaiPYTHONPATH dimenticato di menzionare, la compilazione si lamenterà se non imposti la variabile di ambiente su ciò che usi come prefisso e non riesci a compilare alcuni moduli, ad es. Per estendere l'esempio sopra, imposta PYTHONPATHil prefisso usato in precedenza esempio con export PYTHONPATH=/apps/python-${PYTHON_VERSION}...

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

Se sai dove risiede Libpython, suppongo che sarebbe /usr/local/lib/libpython2.7.so.1.0nel tuo caso, puoi semplicemente creare un link simbolico ad esso:

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

Quindi prova a correre di lddnuovo e vedi se ha funzionato.

Ho installato Python 3.5 di Software Collections su CentOS 7 minimal. Tutto ha funzionato bene da solo, ma ho visto l'errore della libreria condivisa menzionato in questa domanda quando ho provato a eseguire 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 a livello di sistema che funzioni per tutti gli utenti, in modo da escludere l'aggiunta di istruzioni di esportazione a file .profile o .bashrc. Esiste una soluzione a una riga, basata sulla pagina delle soluzioni Red Hat . Grazie per il commento che lo sottolinea:

echo 'source scl_source enable rh-python35' | sudo tee --append /etc/profile.d/python35.sh

Dopo un riavvio, va tutto bene sulla shell, ma a volte il mio server web si lamenta ancora. C'è un altro approccio che ha sempre funzionato sia per la shell che per il server ed è più generico. Ho visto la soluzione qui e poi ho capito che in realtà è menzionata anche in una delle risposte qui! Ad ogni modo, su CentOS 7, questi sono i passaggi:

 vim /etc/ld.so.conf

Che sulla mia macchina aveva appena:

include ld.so.conf.d/*.conf

Quindi ho creato un nuovo file:

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

E aggiunse:

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

E per ricostruire manualmente la cache:

sudo ldconfig

Ecco fatto, gli script funzionano bene!

Questa era una soluzione temporanea, che non funzionava nei riavvii:

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

L'opzione -v (verbosa) 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 chownl'utente ad apache per liberarmi di un errore di autorizzazione dopo quello.

Nota che ho usato find per individuare la directory per la libreria. Puoi anche fare:

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

Che sulla mia macchina virtuale restituisce:

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

Qual è il percorso che devo dare a ldconfig, come mostrato sopra.

Su Solaris 11

Utilizzare LD_LIBRARY_PATH_64per risolvere il collegamento simbolico alle librerie Python.

Nel mio caso per python3.6 LD_LIBRARY_PATHnon ha funzionato ma LD_LIBRARY_PATH_64ha funzionato.

Spero che questo ti aiuti.
Saluti

Questo ha funzionato per me ...

$ sudo apt-get install python2.7-dev

Ho installato usando 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

Quindi ho provato ad eseguire Python e ho ottenuto l'errore:

/ usr / local / bin / python: errore durante il caricamento delle librerie condivise: libpython2.7.so.1.0: impossibile aprire il file oggetto condiviso: nessun file o directory

Quindi, ho effettuato il logout dall'utente root e ho nuovamente provato a eseguire Python e ha funzionato correttamente.

Tutto ciò di cui ha bisogno è l'installazione dell'installazione dei file dev di libpython [3 o 2].

basta installare python-lib. (Python27-lib). Installerà libpython2.7.so1.0. Non è necessario impostare manualmente nulla.