Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Missing compatibility library for krb5 1.2.7|
|Product:||[Fedora] Fedora||Reporter:||Sam Varshavchik <mrsam>|
|Component:||krb5||Assignee:||Nalin Dahyabhai <nalin>|
|Status:||CLOSED CANTFIX||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-04-21 21:04:54 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Sam Varshavchik 2003-11-15 13:46:38 EST
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. How reproducible: Always. Steps to Reproduce: 1. Upgrade RH 9 to FC1. 2. Attempt to invoke any application that linked against either krb5, or openssl Actual results: error while loading shared libraries: libcom_err.so.3: cannot open shared object file: No such file or directory
Comment 1 Nalin Dahyabhai 2003-11-17 09:50:20 EST
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.
Comment 2 Sam Varshavchik 2003-11-17 19:40:05 EST
Why, it's very possible! Executables linked against openssl on RH9 have a direct dependency on libcom_err.so.3: # 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 (0x401a3000) 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 libcom_err.so.3 If this app is not upgraded, it will have an unresolved shared library dependency in FC1.
Comment 3 Nalin Dahyabhai 2003-11-18 12:09:50 EST
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 requires). Any compatibility solution which leads to loading two versions of the same library into a given address space will be unstable.
Comment 4 Sam Varshavchik 2003-11-18 18:48:07 EST
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.
Comment 5 John Haxby 2004-03-22 11:31:37 EST
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.
Comment 6 ami tabak 2004-05-26 10:19:08 EDT
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.
Comment 7 John Thacker 2006-04-21 21:04:54 EDT
Not going to be fixed at this point. Really not going to patch upstream to change the soname.