I compiled Python on one Linux box and copied it to another Linux box. This causes an import problem:
>>> import urllib Traceback (most recent call last): File "<stdin>", line 1, in ? File "/edl3/wb104/analysis/python2.2/lib/python2.2/urllib.py", line 26, in ? import socket File "/edl3/wb104/analysis/python2.2/lib/python2.2/socket.py", line 41, in ? from _socket import * ImportError: libssl.so.0.9.7: cannot open shared object file: No such file or directory On the first Linux box I have: /usr/lib/libssl.so -> /usr/lib/libssl.so.0.9.7 /usr/lib/libssl.so.0.9.7 On the second Linux box I have: /usr/lib/libssl.so -> /lib/lib/libssl.o.0.9.7a /lib/lib/libssl.o.0.9.7a If I create an extra symbolic link on the second Linux box with name libssl.so.0.9.7 (and also one for libcrypto, which has a similar problem) then all is fine. But the problem is that I want to ship a binary distribution to third parties who might not be so confident to do this (and might think I've shipped a duff product). Why is the Linux linker looking for the specific libssl.so.0.9.7 rather than the generic libssl.so? (Obviously on the first Linux box the generic is pointing to the specific, but that's hardly a good excuse.) Is there any (sensible) way to convince it to do otherwise? This problem makes creating binary distributions difficult. (What are the odds that people have exactly the same version of every system library?) -- http://mail.python.org/mailman/listinfo/python-list