Bug 503734
| Summary: | 64bit shared libs in compat-openldap do not link to other libs | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Olivier Fourdan <ofourdan> | ||||
| Component: | openldap | Assignee: | Jan Zeleny <jzeleny> | ||||
| Status: | CLOSED ERRATA | QA Contact: | BaseOS QE <qe-baseos-auto> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 5.3 | CC: | dspurek, jplans, kem, omoris, ovasik, rvokal, tao | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | openldap-2.3.43-12 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2010-03-30 08:05:27 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: | |||||||
| Attachments: |
|
||||||
Created attachment 349775 [details]
Patch fixes linking issue for 64bit systems
I've finally solved the issue. Attached patch adds detection of 64bit systems. Detection was taken from new version of libtool, so it should be fine, however full testing will be done after it is approved for inclusion to RHEL.
Patch is in CVS, changing status to MODIFIED. Is it really fixed? Do we have a regression? See RHTS job http://rhts.redhat.com/cgi-bin/rhts/jobs.cgi?id=126020. RHEL5.5-Server-20100211.0 (x86_64) * openldap 2.3.43 11.el5 (both x86_64 and i386) * compat-openldap 2.3.43_2.2.29 11.el5 (both x86_64 and i386) $ ldd /usr/lib64/libldap-2.2.so.7.0.22 liblber-2.2.so.7 => /usr/lib64/liblber-2.2.so.7 (0x00002ace0f561000) libc.so.6 => /lib64/libc.so.6 (0x00002ace0f781000) /lib64/ld-linux-x86-64.so.2 (0x0000003110200000) $ ldd /usr/lib/libldap-2.2.so.7.0.22 linux-gate.so.1 => (0xffffe000) liblber-2.2.so.7 => /usr/lib/liblber-2.2.so.7 (0xf7f60000) libresolv.so.2 => /lib/libresolv.so.2 (0xf7f4d000) libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0xf7f34000) libssl.so.6 => /lib/libssl.so.6 (0xf7eed000) libcrypto.so.6 => /lib/libcrypto.so.6 (0xf7dab000) libc.so.6 => /lib/libc.so.6 (0xf7c65000) libdl.so.2 => /lib/libdl.so.2 (0xf7c61000) libcrypt.so.1 => /lib/libcrypt.so.1 (0xf7c2f000) libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xf7c02000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xf7b6b000) libcom_err.so.2 => /lib/libcom_err.so.2 (0xf7b68000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xf7b42000) libz.so.1 => /usr/lib/libz.so.1 (0xf7b2f000) /lib/ld-linux.so.2 (0x00351000) libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xf7b26000) libkeyutils.so.1 => /lib/libkeyutils.so.1 (0xf7b23000) libselinux.so.1 => /lib/libselinux.so.1 (0xf7b0a000) libsepol.so.1 => /lib/libsepol.so.1 (0xf7ac4000) You are right, there was a minor glitch in spec file, which prevented correct patch application. Fix is ready, I need to push it to CVS now. Successfully verified via RHTS test. * RHEL5.5-Client (x86_64) * RHEL5.5-Server (x86_64) An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2010-0198.html |
Description of problem: The shared libs in compat-openldap for x86_64 do not list their dependencies on other libs Programs that do not explicitly specify those libraries will fail to run. Version-Release number of selected component (if applicable): compat-openldap-2.3.43_2.2.29-3.el5.x86_64 How reproducible: 100% reproducible Steps to Reproduce: 1. Install compat-openldap for x86_64 2. ldd /usr/lib64/libldap-2.2.so.7.0.22 Actual results: # ldd /usr/lib64/libldap-2.2.so.7.0.22 liblber-2.2.so.7 => /usr/lib64/liblber-2.2.so.7 (0x00002ac21c93b000) libc.so.6 => /lib64/libc.so.6 (0x00002ac21cb68000) /lib64/ld-linux-x86-64.so.2 (0x00002ac21c4e7000) Expected results: # ldd /usr/lib64/libldap-2.2.so.7.0.22 liblber-2.3.so.0 => /usr/lib64/liblber-2.3.so.0 (0x00002ab38e1e4000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00002ab38e410000) libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00002ab38e625000) libssl.so.6 => /lib64/libssl.so.6 (0x00002ab38e83f000) libcrypto.so.6 => /lib64/libcrypto.so.6 (0x00002ab38ea89000) libc.so.6 => /lib64/libc.so.6 (0x00002ab38edda000) libdl.so.2 => /lib64/libdl.so.2 (0x00002ab38f131000) libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00002ab38f335000) libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2 (0x00002ab38f56d000) libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00002ab38f79c000) libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00002ab38fa31000) libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00002ab38fc33000) libz.so.1 => /usr/lib64/libz.so.1 (0x00002ab38fe59000) /lib64/ld-linux-x86-64.so.2 (0x00002ab38dd90000) libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00002ab39006d000) libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00002ab390275000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00002ab390478000) libsepol.so.1 => /lib64/libsepol.so.1 (0x00002ab390690000) Additional info: The problem does not happen for i386, on the same system: # ldd /usr/lib/libldap-2.2.so.7.0.22 linux-gate.so.1 => (0xffffe000) liblber-2.2.so.7 => /usr/lib/liblber-2.2.so.7 (0xf7f31000) libresolv.so.2 => /lib/libresolv.so.2 (0xf7f1e000) libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0xf7f05000) libssl.so.6 => /lib/libssl.so.6 (0xf7ebe000) libcrypto.so.6 => /lib/libcrypto.so.6 (0xf7d7d000) libc.so.6 => /lib/libc.so.6 (0xf7c39000) libdl.so.2 => /lib/libdl.so.2 (0xf7c35000) libcrypt.so.1 => /lib/libcrypt.so.1 (0xf7c03000) libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0xf7bd5000) libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0xf7b3e000) libcom_err.so.2 => /lib/libcom_err.so.2 (0xf7b3b000) libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0xf7b15000) libz.so.1 => /usr/lib/libz.so.1 (0xf7b02000) /lib/ld-linux.so.2 (0xf7f94000) libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xf7af9000) libkeyutils.so.1 => /lib/libkeyutils.so.1 (0xf7af6000) libselinux.so.1 => /lib/libselinux.so.1 (0xf7add000) libsepol.so.1 => /lib/libsepol.so.1 (0xf7a97000) Additionally the build log shows messages like: *** Warning: linker path does not have real file for library -lbind. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libbind but no candidates were found. (...for file magic test) *** Warning: linker path does not have real file for library -lsasl2. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libsasl2 but no candidates were found. (...for file magic test) Same with other libs like resolv, sasl2, ssl, crypto. But this seems to be related to the build environments as the same package rebuilt on my system correctly lists all the shared libs.