dynamical linking problem

W

wab104

I compiled Python on one Linux box and copied it to another Linux box.
This causes an import problem:
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?)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,054
Latest member
TrimKetoBoost

Latest Threads

Top