linux - How to diagnosis and resolve: /usr/lib64/libz.so.1: no version information available

I had a hell of a time installing lxml for Python 2.7 on CentOS 5.6. For some background, Python 2.7 is an alternative installation of Python on CentOS 5.6 which comes with Python 2.4 installed.

it was bulit from source per its instrucitons

./configure
make
make altinstall

However, after about 20 hours of trying I managed to find a workable solution and was able to install lxml.

Until, I notice the following error at the top of the interpreter:

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!'

This error is printed out everytime I run a script.

For example:

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

The script runs flawlessly, but this error is bothersome. After some digging I have seem to believe I have a wrong version of libz installed, that it is either an older version or built for a different platform.

I'm not quite sure how, I've only installed libz through yum, as far as I know. Although, I can't quite remember every little thing I tried in my twenty hours of trying.

You may also be intereted in what my lib64 folder looks like, here is some information

$ 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

Notice: the items that Say Jul 1st or Jun 30th are from me. I had initially moved these files into a backup folder as they seeemed to be duplicates and had a date after/during my problems I alluded to earlier that I had with lxml

One inclination is to completely remove Python 2.7 and re-install. I think having it install to /usr/local/ was a poor default choice. However, without the make uninstall option being present it seems to be a time consuming task for a solution I am not quite sure would solve my problem.

From What does the “no version information available” error from linux dynamic linker mean?, pertaining to 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.)

I have multiple version on my system and ran into the same issue. Under /usr/bin I created the python-2.4.3 file and pointed it to python which fixed my issue. the python-2.4.3 was erased some how after the compiling of my other versions that we are using. I believe that the yum application which is built within python 2.4.3 is the issue.

yum install python-lxml

Should do the trick