Strange "ldd" behaviour on shared libs
I compiled a shared lib (from e2fsprogs). Trying to fond out why my
last compile built binaries depending on both libc5 and lib6, I ran
ldd on all I could find, including shared libs. I got for some libs
the following answer:
=====
$ ldd libss.so.2.0
libc.so.5 => /lib/libc.so.5 (0x40007000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0x400c3000)
$ cd ..
$ ldd ss/libss.so.2.0
libc.so.6 => /lib/libc.so.6 (0x40007000)
--list => --list (0x00000000)
libcom_err.so.2 => /lib/libcom_err.so.2 (0x400a5000)
libc.so.5 => /lib/libc.so.5 (0x400a7000)
=====
After reading ldd.1, I wonder whether it does mean anything (nothing
told about shared libs deps; don't even know whether it's implemented
somewhere).
Anyway, the 1st run really seems relevant. The reference to libc5 may
come from the fact that ldd looks at a libc5 libcom_err in /lib, but
then why doesn't it show in the 1st case ?
And what's that "--list" that looks like an argument to some program ?
Any clue, someone ?
--
Yann Dirson <dirson@univ-mlv.fr> | Stop making M$-Bill richer & richer,
alt-email: <ydirson@a2points.com> | support Debian GNU/Linux:
| more powerful, more stable !
http://www.a2points.com/homepage/3475232 |
-----------------------------------------
A computer engineer's looking for a job !
-----------------------------------------
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: