Bug 155951 - /usr/lib64/libldap_r.so.2.0.130 does not contain correct dependencies.
Summary: /usr/lib64/libldap_r.so.2.0.130 does not contain correct dependencies.
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: openldap
Version: 4.0
Hardware: x86_64
OS: Linux
Target Milestone: ---
: ---
Assignee: Nalin Dahyabhai
QA Contact: Jay Turner
Depends On:
TreeView+ depends on / blocked
Reported: 2005-04-26 01:00 UTC by Dennis
Modified: 2015-01-08 00:09 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2005-04-27 08:00:25 UTC

Attachments (Terms of Use)

Description Dennis 2005-04-26 01:00:31 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0

Description of problem:
Bug item 149043 is now also confirmed to exist on Red Hat EL 4 x86_64.

The 64-bit /usr/lib64/libldap_r.so.2.0.130 library does NOT contain
the correct dependencies.

The 32-bit /usr/lib/libldap_r.so.2.0.130 library on the other hand
does contain the correct dependencies.

I reported the Fedora Core 3 bug back in early Febuary and have
received no reply. This bug (especially now on Red Hat EL4) effects us
and our customers greatly.

We consider this an "extremely high severity" issue. 


Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
# readelf -a /usr/lib64/libldap_r.so.2.0.130 | grep NEEDED


Actual Results:  ... Shared library: [liblber-2.2.so.7]
... Shared library: [libresolv.so.2]
... Shared library: [libdl.so.2]
... Shared library: [libc.so.6]

Expected Results:   0x00000001 (NEEDED)                     Shared library: [liblber-2.2.so.7]
 0x00000001 (NEEDED)                     Shared library: [libresolv.so.2]
 0x00000001 (NEEDED)                     Shared library: [libdl.so.2]
 0x00000001 (NEEDED)                     Shared library: [libsasl2.so.2]
 0x00000001 (NEEDED)                     Shared library: [libssl.so.4]
 0x00000001 (NEEDED)                     Shared library: [libcrypto.so.4]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]

Additional info:

The supplied 32-bit library does contain the correct dependencies

The 32-bit library is correct.

# readelf -a /usr/lib/libldap_r.so.2.0.130 | grep NEEDED

... Shared library: [liblber-2.2.so.7]
... Shared library: [libresolv.so.2]
... Shared library: [libdl.so.2]
... Shared library: [libsasl2.so.2]
... Shared library: [libssl.so.4]
... Shared library: [libcrypto.so.4]
... Shared library: [libc.so.6]

Comment 1 Suzanne Hillman 2005-04-26 16:00:19 UTC
If this is a high urgency thing, please contact support by going to
http://www.redhat.com/support or calling 800-REDHAT1

Comment 2 Dennis 2005-04-27 03:10:24 UTC
I carried out more testing and it does appear that the 64-bit
libldap_r.so.2.0.130 is useable under Red Hat EL4 whilst it
is not under FC3.

Under Fc3 (x86_64) our application fails with the following 

> Unable to load library 'libAceLdap.so': /usr/lib64/libldap_r.so.2:
> undefined symbol: SSL_CTX_set_tmp_rsa_callback.

That problem does not occur under RHEL4 (x86_64). The md5sums
of the /usr/lib65/libldap_r.so.2.0.130 are the same on Fc3 and RHEL4.

It must be another issue under FC3 (ld.so.cache??). Confusing.
The built in dependencies appears to be a red herring.

Apologies for the false alarm. Please close this bug item as it
is not a problem under RHEL4. I will update the FC3 bug item with
the extra information.



Comment 3 Dennis 2005-04-27 03:36:31 UTC
I now know what is going on here.

Our application was compiled on Red Hat EL3. This build
fails to load up the sub-dependencies of /usr/lib64/libldap_r.so.2.0.130
when run on FC3.

We have now started building our application on Red Hat EL4. This build
does work with respect to loading up the sub-dependencies 
of /usr/lib64/libldap_r.so.2.0.130 on FC3.

I believe the problem relates to our build. This problem was disguised
when run on Red Hat 3 (due to exact library matches build & run). 
However, when run on a installation where the run libraries differ
from the build libraries then we run into trouble.

Apologies for taking up your time. Problem solved.



Comment 4 Jay Turner 2005-04-27 08:00:25 UTC
Closing out this issue, as all appears to be well now.

Note You need to log in before you can comment on or make changes to this bug.