Executável Python não encontra a biblioteca compartilhada libpython

Estou instalando o Python 2.7 no CentOS 5. Criei e instalei o Python da seguinte maneira

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

Quando tento executar / usr / local / bin / python, recebo esta mensagem de erro

/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 executo o ldd em / usr / local / bin / python, recebo

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)

Como digo ao Python onde encontrar o libpython?

Tente o seguinte:

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

Substitua /usr/local/libpela pasta em que você instalou, libpython2.7.so.1.0se não estiver /usr/local/lib.

Se isso funcionar e você deseja tornar as alterações permanentes, você tem duas opções:

1. Adicione export LD_LIBRARY_PATH=/usr/local/libao seu .profilediretório inicial (isso funciona apenas se você estiver usando um shell que carrega esse arquivo quando uma nova instância do shell é iniciada). Essa configuração afetará apenas seu usuário.

2. Adicionar /usr/local/libpara /etc/ld.so.confe executar ldconfig. Esta é uma configuração de todo o sistema, é claro.

Vestindo meu chapéu de coveiro ...

A melhor maneira que encontrei para resolver isso é em tempo de compilação. Como você é o único prefixo de configuração, de qualquer maneira, é possível dizer explicitamente ao executável onde encontrar suas bibliotecas compartilhadas. Diferentemente do OpenSSL e de outros pacotes de software, o Python não fornece diretrizes de configuração agradáveis ​​para lidar com caminhos alternativos da biblioteca (nem todo mundo é root que você conhece ...) No caso mais simples, tudo o que você precisa é o seguinte:

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

Ou se você preferir a versão não-linux:

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

O rpathsinalizador " " informa ao python que ele possui bibliotecas de tempo de execução necessárias nesse caminho específico. Você pode levar essa idéia adiante para lidar com dependências instaladas em um local diferente dos locais padrão do sistema. Por exemplo, em meus sistemas, já que não tenho acesso root e preciso fazer instalações Python quase completamente independentes, minha linha de configuração fica assim:

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

Neste caso estou compilando as bibliotecas que usos Python (como ffi, readline, etc) em um extlibdiretório dentro da própria árvore de diretórios python. Dessa forma, eu posso tar o diretório python - $ {PYTHON_VERSION} e pousá-lo em qualquer lugar e ele "funcionará" (desde que você não tenha conflitos libcou libmconflitos). Isso também ajuda ao tentar executar várias versões do Python na mesma caixa, pois você não precisa mudar constantemente LD_LIBRARY_PATHou se preocupar em escolher a versão errada da biblioteca Python.

Edit: Esqueci de mencionar, a compilação se queixará se você não definir a PYTHONPATHvariável de ambiente como o seu prefixo e falhar na compilação de alguns módulos, por exemplo, para estender o exemplo acima, defina PYTHONPATHo prefixo usado no exemplo acima exemplo com export PYTHONPATH=/apps/python-${PYTHON_VERSION}...

Eu tive o mesmo problema e resolvi-o desta maneira:

Se você sabe onde reside o libpython, eu acho que seria /usr/local/lib/libpython2.7.so.1.0no seu caso, você pode simplesmente criar um link simbólico para ele:

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

Em seguida, tente executar lddnovamente e veja se funcionou.

Instalei o Python 3.5 da Software Collections no mínimo no CentOS 7. Tudo funcionou bem por conta própria, mas vi o erro da biblioteca compartilhada mencionado nesta pergunta quando tentei executar um script CGI simples:

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

Eu queria uma solução permanente em todo o sistema que funcionasse para todos os usuários, de modo a excluir a adição de instruções de exportação em arquivos .profile ou .bashrc. Existe uma solução de uma linha, baseada na página de soluções da Red Hat . Obrigado pelo comentário que aponta:

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

Após uma reinicialização, tudo fica bem no shell, mas às vezes meu servidor da web ainda reclama. Há outra abordagem que sempre funcionou para o shell e o servidor e é mais genérica. Vi a solução aqui e percebi que também é mencionada em uma das respostas aqui! De qualquer forma, no CentOS 7, estas são as etapas:

 vim /etc/ld.so.conf

Que na minha máquina tinha apenas:

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

Então eu criei um novo arquivo:

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

E acrescentou:

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

E para recriar manualmente o cache:

sudo ldconfig

É isso aí, os scripts funcionam bem!

Esta foi uma solução temporária, que não funcionou nas reinicializações:

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

A opção -v (detalhada) era apenas para ver o que estava acontecendo. Eu vi que ele fez: / 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

Este erro em particular foi embora. Aliás, eu tive que chowno usuário apache para se livrar de um erro de permissão depois disso.

Observe que eu usei o find para localizar o diretório da biblioteca. Você também pode fazer:

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

Que na minha VM retorna:

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

Qual é o caminho que preciso fornecer ao ldconfig, como mostrado acima.

No Solaris 11

Use LD_LIBRARY_PATH_64para resolver o link simbólico para bibliotecas python.

No meu caso, para python3.6 LD_LIBRARY_PATHnão funcionou, mas LD_LIBRARY_PATH_64funcionou.

Espero que isto ajude.
Saudações

Isso funcionou para mim ...

$ sudo apt-get install python2.7-dev

Eu instalei usando o comando:

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

make

Agora, como usuário root:

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

Então eu tentei executar python e recebi o erro:

/ usr / local / bin / python: erro ao carregar bibliotecas compartilhadas: libpython2.7.so.1.0: não é possível abrir o arquivo de objeto compartilhado: Esse arquivo ou diretório não existe

Então, eu saí do usuário root e tentei novamente executar o Python e funcionou com sucesso.

Tudo o que precisa é a instalação da instalação dos arquivos dev libpython [3 ou 2].

basta instalar o python-lib. (python27-lib). Ele instalará o libpython2.7.so1.0. Não precisamos definir nada manualmente.