FS#29914 - [ltrace] bad libcap.so linkage
Attached to Project:
Arch Linux
Opened by Sébastien Luttringer (seblu) - Wednesday, 16 May 2012, 16:34 GMT
Last edited by Evangelos Foutras (foutrelis) - Wednesday, 23 May 2012, 16:17 GMT
Opened by Sébastien Luttringer (seblu) - Wednesday, 16 May 2012, 16:34 GMT
Last edited by Evangelos Foutras (foutrelis) - Wednesday, 23 May 2012, 16:17 GMT
|
Details
Description:
$ ltrace -p $$ ltrace: Can't open "/lib/libcap.so.2": No such file or directory Additional info: * package version(s): 0.6.0-1 * config and/or log files etc. |
This task depends upon
Closed by Evangelos Foutras (foutrelis)
Wednesday, 23 May 2012, 16:17 GMT
Reason for closing: Not a bug
Wednesday, 23 May 2012, 16:17 GMT
Reason for closing: Not a bug
$ readelf -d /usr/bin/ltrace | grep NEEDED
0x0000000000000001 (NEEDED) Shared library: [libelf.so.1]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
I can't reproduce the error message with the command you posted either.
In this machine, the coreutils's package is replaced by busybox for create a tiny machine. (libcap is an dependency of coreutils)
No link with libcap :
$ ldd /usr/bin/ltrace
linux-gate.so.1 => ...
libelf.so.1 => ...
libc.so.6 => ...
/lib/ld-linux.so.2 ...
This command work properly and does not return error.
$ ltrace -p $$ # a zsh process
ltrace: Can't open "/lib/libcap.so.2": No such file or directory
$ cat /proc/3066/maps|grep libcap
7ffee3cb2000-7ffee3cb6000 r-xp 00000000 09:01 9961560 /lib/libcap.so.2.22 (deleted)
7ffee3cb6000-7ffee3eb5000 ---p 00004000 09:01 9961560 /lib/libcap.so.2.22 (deleted)
7ffee3eb5000-7ffee3eb6000 rw-p 00003000 09:01 9961560 /lib/libcap.so.2.22 (deleted)
libcap was updated 8 May. This update move libs and binary from / to /usr/.
$ grep libcap pacman.log|tail -n 1
[2012-05-08 03:26] upgraded libcap (2.22-2 -> 2.22-3)
All zsh process launched before 8/5/2012 fails. All after works.
Idem with moving of acl from / to /usr.
grep "acl" /var/log/pacman.log|tail -n 1
[2012-05-08 03:26] upgraded acl (2.2.51-1 -> 2.2.51-2)
All processes using acl, launched before update, cause ltrace to fail:
$ ltrace -p 30352 # kdeinit process
ltrace: Can't open "/lib/libacl.so.1": No such file or directory
My theory is ltrace is trying to open library used by program, and if not exists fail.
Fail occur in ltrace-elf.c in do_init_elf function after crawling process maps to find used library.
So, you can close, it's not a ltrace related bug, but /usr move one.