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