Bug 110166
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: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 1 | CC: | jch |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-04-22 01:04:54 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Sam Varshavchik
2003-11-15 18:46:38 UTC
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 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. 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. 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. |