Como diagnosticar e resolver: /usr/lib64/libz.so.1: nenhuma informação de versão disponível

Question

Eu teve um tempo infernal instalando lxml para o Python 2.7 no CentOS 5.6. Para alguns contextos, o Python 2.7 é uma instalação alternativa do Python no CentOS 5.6, que vem com o Python 2.4 instalado.

foi bulit de fonte por suas instruções

./configure
make
make altinstall

No entanto, após cerca de 20 horas de tentativas, consegui encontrar uma solução viável e consegui instalar lxml .

Até que, percebo o seguinte erro no topo do interpretador:

python2.7: /usr/lib64/libz.so.1: no version information available (required by python2.7)
Python 2.7.2 (default, Jun 30 2011, 18:55:26) 
[GCC 4.1.2 20080704 (Red Hat 4.1.2-50)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print 'Sheeeeut!'

Esse erro é impresso toda vez que eu executo um script.

Por exemplo:

$ ./test.py
/usr/local/bin/python2.7: /usr/lib64/libz.so.1: no version information available (required by /usr/local/bin/python2.7)

O script é executado sem falhas, mas esse erro é incômodo. Depois de algumas escavações, parece que acredito que tenho uma versão incorreta do libz instalado, que é uma versão mais antiga ou criada para uma plataforma diferente.

Não sei bem como, instalei apenas libz até yum , até onde sei. Embora eu não consiga me lembrar de cada pequena coisa que tentei em minhas vinte horas de tentativas.

Você também pode ser interposto em como minha pasta lib64 se parece, aqui estão algumas informações

$ ls -ltrh libz*
-rwxr-xr-x 1 root root  84K Jan  9  2007 libz.so.1.2.3
-rwxr-xr-x 1 root root 107K Jan  9  2007 libz.a
-rwxr-xr-x 1 root root 154K Feb 22 23:30 libzdb.so.7.0.2
lrwxrwxrwx 1 root root   13 Apr 20 20:46 libz.so.1 -> libz.so.1.2.3
lrwxrwxrwx 1 root root   15 Jun 30 18:43 libzdb.so.7 -> libzdb.so.7.0.2
lrwxrwxrwx 1 root root   13 Jul  1 11:35 libz.so -> libz.so.1.2.3
lrwxrwxrwx 1 root root   15 Jul  1 11:35 libzdb.so -> libzdb.so.7.0.2

Aviso: os itens que dizem 1 de julho ou 30 de junho são de mim. Inicialmente, movi esses arquivos para uma pasta de backup, pois eles pareciam ser duplicados e tinham uma data após / durante meus problemas que aludi anteriormente e que tive com lxml

Uma tendência é remover completamente o Python 2.7 e reinstalar. Acho que instalá-lo em /usr/local/ foi uma opção padrão ruim. No entanto, sem a opção make uninstall estar presente, parece ser uma tarefa demorada para uma solução que não tenho certeza se resolveria meu problema.

    

Answer 1

Em O que significa o erro “nenhuma informação disponível na versão” do linkador dinâmico do linux? , referente à libpam:

The "no version information available" means that the library version number is lower on the shared object. For example, if your major.minor.patch number is 7.15.5 on the machine where you build the binary, and the major.minor.patch number is 7.12.1 on the installation machine, ld will print the warning.

You can fix this by compiling with a library (headers and shared objects) that matches the shared object version shipped with your target OS. E.g., if you are going to install to RedHat 3.4.6-9 you don't want to compile on Debian 4.1.1-21. This is one of the reasons that most distributions ship for specific linux distro numbers.

Otherwise, you can statically link. However, you don't want to do this with something like PAM, so you want to actually install a development environment that matches your client's production environment (or at least install and link against the correct library versions.)

    

Answer 2

Eu tenho várias versões no meu sistema e encontrei o mesmo problema. Em /usr/bin , criei o arquivo python-2.4.3 e apontei para python, o que corrigiu meu problema. o python-2.4.3 foi apagado de alguma forma após a compilação das minhas outras versões que estamos usando. Eu acredito que o aplicativo yum que é construído dentro do python 2.4.3 é o problema.

    

Answer 3

yum install python-lxml

Deve fazer o truque