Description of problem:
After upgrading from Red Hat 9, applications that use krb5 **which
includes all applications that link against OpenSSL, since RH9's
OpenSSL uses krb5** no longer work.
Steps to Reproduce:
1. Upgrade RH 9 to FC1.
2. Attempt to invoke any application that linked against either krb5,
error while loading shared libraries: libcom_err.so.3: cannot open
shared object file: No such file or directory
I don't think this is possible (would that it were). Some of the
libraries which are required by libssl have changed sonames
(libcom_err), but some have not (libkrb5), and the run-time linker has
nothing more to work with when determining which library to load.
Why, it's very possible!
Executables linked against openssl on RH9 have a direct dependency on
# ldd /usr/bin/ssh
libresolv.so.2 => /lib/libresolv.so.2 (0x4001b000)
libutil.so.1 => /lib/libutil.so.1 (0x4002d000)
libz.so.1 => /usr/lib/libz.so.1 (0x40030000)
libnsl.so.1 => /lib/libnsl.so.1 (0x4003f000)
libcrypto.so.4 => /lib/libcrypto.so.4 (0x40054000)
libkrb5.so.3 => /usr/kerberos/lib/libkrb5.so.3 (0x40145000)
libk5crypto.so.3 => /usr/kerberos/lib/libk5crypto.so.3
libcom_err.so.3 => /usr/kerberos/lib/libcom_err.so.3 (0x401b3000)
libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
libdl.so.2 => /lib/libdl.so.2 (0x401b5000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
[root@brimstone root]# strings /usr/bin/ssh | grep libcom_err.so.3
If this app is not upgraded, it will have an unresolved shared library
dependency in FC1.
Yes, so this app must be upgraded, because libcom_err.so.3, which was
part of the krb5-libs package, is no longer there. The libkrb5.so.3
which is in krb5-libs, and applications which have been linked against
it, now depend on libcom_err.so.2.
If libcom_err.so.3 were to suddenly reappear, applications which
required both libcom_err.so.3 and libkrb5.so.3 would have two versions
of the libcom_err library loaded by the dynamic linker at startup-time
(the one which the application requires, and the one which libkrb5
Any compatibility solution which leads to loading two versions of the
same library into a given address space will be unstable.
This is now going to be needed for every application that's built
against OpenSSL. This begs for inclusion in release notes.
libkrb5's soname should've been bumped in FC1, since then binary API
changed. Just like OpenSSL's soname gets bumped with every minor
point release, due to internal API changes.
Then, applications built on FC1 would've pulled libkrb5.so.4 and
libcom_err.so.2. Pre-FC1 applications could've used a libkrb5.so.3
and libcom_err.so.3 compatibility libraries.
This is a deeply unpleasant feature. Previously, we've been able to
build on earlier releases and run on later releases provided the right
compatability libraries have been installed.
The fact that libcom_err.so is no longer present and libkrb5.so has
the same version number (.3) as previously would seem to make it very
difficult to get out of this hole.
Although I don't hold out much hope of this being fixable, I really
would like a fix.
found a temporary solution, till an offical workaround is released
in the /lib I created a soft link as
libcom_err.so.3 -> /lib/libcom_err.so.2.1
booted mozilla 1.7 and it worked.
If it works for you as well please add a comment so we can gather data.
Not going to be fixed at this point. Really not going to patch upstream to
change the soname.