Bug 156057 - ldd does not on 2.4.21-27
Summary: ldd does not on 2.4.21-27
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: glibc   
(Show other bugs)
Version: 3.0
Hardware: ia64 Linux
medium
high
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-04-27 06:19 UTC by Vaibhav Khanduja
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version: 2.3.2-95.27
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-13 16:45:47 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Vaibhav Khanduja 2005-04-27 06:19:47 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

Description of problem:
I am trying to execute ldd on one of my executable it is printing false output.

ldd ./rpcd
        not a dynamic executable



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

How reproducible:
Always

Steps to Reproduce:
1.execute ldd on any executable which has some shared objects linked.
2.
3.
  

Actual Results:  ldd prints  "not a dynamic executable"

Expected Results:  Should have given all the shared objects the executable links.

Additional info:

The kernel 2.4.21-27 panics when any 32 bit application runs, I have the fix specified in 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=149965. 

But this ldd issue I could see even before applying the fix.

Comment 1 Ernie Petrides 2005-04-27 20:41:09 UTC
Hello, Vaibhav.  Here's the output I get from "ldd /bin/ls":

        libacl.so.1 => /lib/libacl.so.1 (0x0064a000)
        libtermcap.so.2 => /lib/libtermcap.so.2 (0x00864000)
        libc.so.6 => /lib/tls/libc.so.6 (0x00217000)
        libattr.so.1 => /lib/libattr.so.1 (0x00a0c000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00201000)

Perhaps you're not running "ldd" on an appropriate executable.

At any rate, this is not a kernel problem, so I'll reassign this to
the "glib" component (since /usr/bin/ldd is in the glibc-common RPM).

Comment 2 Vaibhav Khanduja 2005-04-28 05:21:39 UTC
I am actually running ldd on a correct executable. I had actaully moved from
2.4.21-15 to 2.4.21-27. I just checked on 2.4.21-15 it is not working there
either. There might be something glibc. I have glibc-common-2.3.2-95.20
installed  on my system. 

Comment 3 Vaibhav Khanduja 2005-04-28 14:50:42 UTC
I guess I have figured out why ldd is not working for me. We are running our
application in emulated mode, a 32 bit on 64bit platforms. We pick some of the
libraries from /emul/ia32-Linux/lib. ldd is a script which by default is not
checking in this directory a small change in ldd would make this happen. The
change is listed below 30 should look like 
line number 
RTLDLIST="/emul/ia32-linux/lib/ld-linux.so.2 /lib/ld-linux-ia64.so.2
/lib/ld-linux.so.2"

instead of 
RTLDLIST="/lib/ld-linux-ia64.so.2 /lib/ld-linux.so.2"

I guess this fix should be added in the next release.

Comment 4 Jakub Jelinek 2005-05-13 16:45:47 UTC
It was actually already added in RHEL3 U3.
Make sure you use glibc{,-common}-2.3.2-95.27 or newer.


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