Thomas Bächler wrote:
Am 27.10.2011 10:38, schrieb clemens fischer:
minilogd requires the following libs:
-rwxr-xr-x 1 root root 11K Oct 18 18:34 /usr/sbin/minilogd lrwxrwxrwx 1 root root 12 Sep 9 01:23 /usr/lib32/libc.so.6 -> libc-2.14.so -rwxr-xr-x 1 root root 1.4M Sep 9 01:23 /usr/lib32/libc-2.14.so /usr/lib32/libc.so.6: lrwxrwxrwx 1 root root 26 Sep 9 01:23 /lib/ld-linux.so.2 -> ../usr/lib32/ld-linux.so.2 -rwxr-xr-x 1 root root 141K Sep 9 01:23 /usr/lib32/ld-2.14.so
I don't know why it asks for libs out of usr/lib32, this output is from (the recursive use of) readelf(1). This is on a 64bit PC.
Where do you get that from?
$ ldd /usr/sbin/minilogd linux-vdso.so.1 => (0x00007fff09d0c000) libc.so.6 => /lib/libc.so.6 (0x00007f9c3fc9b000) /lib/ld-linux-x86-64.so.2 (0x00007f9c40022000) $ readelf -d /usr/sbin/minilogd | grep library 0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
I'm really glad you asked! I have a script called "missing-libs.sh", and quite a number of self compiled programs. Whenever pacman upgrades my system, some libs required by my programs may vanish, so "missing-libs.sh" is used to scan my entire usr/local/{{s,}bin,lib,libexec} recursively to check that the programs get to keep their dependencies. It uses "readelf -d" instead of ldd(1), because the latter actually runs any binary, which I can't afford for security reasons. Readelf prints a "NEEDED" entry for dependencies besides other info, but (normally) without a path, so the script has an init stage where all libs reported by "ldconfig -p" are cashed in an array to have path info at hand. I have to do this, because some lib may require further libs which have to be checked recursively. $ readelf -d /usr/sbin/minilogd Dynamic section at offset 0x1e50 contains 20 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] ... $ readelf -d /lib/libc.so.6 Dynamic section at offset 0x159b40 contains 27 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [ld-linux-x86-64.so.2] ... "ld-linux-x86-64.so.2" had no entry "NEEDED", so my script stops there. Now your question points out a bug: the first lib found is displayed, and this may be a 32bit lib! I'll have to come up with a fix for that that avoids ldd(1). My system was converted from 32 bit to 64 bit not long ago, the script had been working for so long, it just didn't cross my mind that the caching was at fault. I just see that: $ readelf -h /usr/sbin/minilogd ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 ... So I'll have to account for that "Class" attribute of binaries. Oh well, I need to avoid ldd, so it has to be done. Hmm, unless I can efficiently sandbox ldd, entire directories need to be scanned afterall ... clemens