dynamical linking problem

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • wab104

    #1

    dynamical linking problem

    I compiled Python on one Linux box and copied it to another Linux box.
    This causes an import problem:
    [color=blue][color=green][color=darkred]
    >>> import urllib[/color][/color][/color]
    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?)
Working...