Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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.

share|improve this question
    
I never did find a working solution to this. Unfortunately, I have set this project aside for the past 10 months. –  matchew Sep 28 '12 at 4:14

3 Answers 3

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.)

share|improve this answer
    
Yeah, that is exactly what I've looked at. I knew this is the problem, but I do not know what I need to do to fix this. I am guessing the culprit is this: /usr/lib64/libz.so.1 but from there I am not sure how to proceed. Thanks for giving this question at least a try. –  matchew Jul 9 '11 at 16:37
    
The possible fixes were listed above : (1) recompile your product using a lower-level library, (2) link your product statically so as not to use the local shared version. I don't see a 3rd solution, but maybe someone else here will. –  harrymc Jul 9 '11 at 17:35

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.

share|improve this answer
yum install python-lxml

Should do the trick

share|improve this answer
    
Please learn to use the formatting tools available for your answers, thank you. –  slhck Feb 23 '12 at 15:10

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.