dynamical linking problem

wab104 wab104 at hotmail.com
Tue Nov 30 14:17:13 CET 2004


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



More information about the Python-list mailing list