[csw-users] problem with library versioning
David Houlder
david.houlder at anu.edu.au
Tue Sep 27 06:20:13 CEST 2005
Hi...
I think there's a problem with the blastwave shareable object versioning
setup, at least for libssl.so and libcrypto.so. I am running into the
following problem:
A few months ago I compiled pubcookie (see
http://www.pubcookie.org/about.html ). It uses libssl and libcrypto, and
I built it to use /opt/csw/lib/lib{ssl,crypto}.so
At that time, both libssl and libcrypto were version 0.9.7, so I got this...
[djh900 at flix pubcookie-3.2.0]$ ldd \ /opt/pubcookie/current/login/index.cgi
libssl.so.0.9.7 => /opt/csw/lib/libssl.so.0.9.7
libcrypto.so.0.9.7 => /opt/csw/lib/libcrypto.so.0.9.7
[...]
libldap.so.2 => /opt/csw/lib/libldap.so.2
... due to...
[djh900 at flix pubcookie-3.2.1a]$ elfdump -d \
/opt/csw/lib/libssl.so.0.9.7 | fgrep SONAME
[7] SONAME 0x24f0 libssl.so.0.9.7
As you can see from the ldd above, pubcookie also depends on
/opt/csw/lib/libldap.so.2. At the time pubcookie was built, libldap.so.2
used /opt/csw/lib/lib{ssl,crypto}.so.0.9.7 and it all worked.
We recently updated /opt/csw/lib/libldap*, so now we have...
[djh900 at flix pubcookie-3.2.0]$ ldd /opt/csw/lib/libldap.so.2
[...]
libssl.so.0.9.8 => /opt/csw/lib/sparcv8plus/libssl.so.0.9.8
libcrypto.so.0.9.8 => /opt/csw/lib/sparcv8plus/libcrypto.so.0.9.8
So now...
[djh900 at flix pubcookie-3.2.1a]$ ldd -v \
/opt/pubcookie/current/login/index.cgi
find object=libssl.so.0.9.7; required by
/opt/pubcookie/3.2.0/login/index.cgi
libssl.so.0.9.7 => /opt/csw/lib/libssl.so.0.9.7
find object=libcrypto.so.0.9.7; required by
/opt/pubcookie/3.2.0/login/index.cgi
libcrypto.so.0.9.7 => /opt/csw/lib/libcrypto.so.0.9.7
[...]
find object=libssl.so.0.9.8; required by /opt/csw/lib/libldap.so.2
libssl.so.0.9.8 => /opt/csw/lib/sparcv8plus/libssl.so.0.9.8
find object=libcrypto.so.0.9.8; required by /opt/csw/lib/libldap.so.2
libcrypto.so.0.9.8 =>
/opt/csw/lib/sparcv8plus/libcrypto.so.0.9.8
In other words, pubcookie now depends on both lib{ssl,crypto}.0.9.7 and
(through libldap) lib{ssl,crypto}.0.9.8.
What seems to be happening is that lib{ssl,crypto}.0.9.7 is loaded
first, which satisfies all the symbol references in pubcookie and
libldap, so lib{ssl,crypto}.0.9.8 never gets loaded. It appears that
libldap.so.2 only works with lib{ssl,crypto}.0.9.8, because when the
latest libldap.so.2 was installed, 'ldaps://' URLs stopped working in
pubcookie, but 'ldap://' kept on working.
I can get around this temporarily by relinking pubcookie so it picks up
lib{ssl,crypto}.0.9.8, but that's only good until the next update of
libldap. Not a satisfactory state of affairs.
Now look at this:
[djh900 at flix pubcookie-3.2.1a]$ ldd /opt/csw/apache/bin/httpd
[...]
libssl.so.0.9.7 => /opt/csw/lib/sparcv8plus/libssl.so.0.9.7
libcrypto.so.0.9.7 =>
/opt/csw/lib/sparcv8plus/libcrypto.so.0.9.7
[...]
libssl.so.0.9.8 => /opt/csw/lib/sparcv8plus/libssl.so.0.9.8
libcrypto.so.0.9.8 =>
/opt/csw/lib/sparcv8plus/libcrypto.so.0.9.8
[...]
i.e. it looks like the csw apache may have the same problem.
I see that Red Hat have got around this by...
[djh900 at dh ~]$ objdump -x /usr/lib/libssl.so| fgrep SONAME
SONAME libssl.so.4
[djh900 at dh ~]$ ldd /usr/lib/libldap.so|fgrep libssl
libssl.so.4 => /lib/libssl.so.4 (0x00269000)
[djh900 at dh ~]$ ls -l /lib/libssl.so.4
lrwxrwxrwx 1 root root 16 Feb 28 2005 /lib/libssl.so.4 -> libssl.so.0.9.7a
[djh900 at dh ~]$
In other words, things linked against libssl.so record a dependency on
libssl.so.4, not libssl.0.9.x, so (assuming ABI compatibility etc),
libssl can be updated, the libssl.so.4 symlink retargeted, and
everything that uses libssl starts using the latest libssl.
I think the csw libs need to do something similar.
Any thoughts?
cheers
David Houlder
--
David.Houlder at anu.edu.au ANU Supercomputer Facility
Phone: +61 2 6125 0578 and APAC National Facility
Fax: +61 2 6125 8199 Leonard Huxley Bldg (No. 56)
Australian National University
Canberra, ACT, 0200, Australia
More information about the users
mailing list