Description of problem: The ltrace-0.3.29-1 package seems to be completely useless. Only malloc()/free() and sometimes close() is shown. Version-Release number of selected component (if applicable): 0.3.29-1 For example: $ ltrace true +++ exited (status 0) +++ Expected: $ ltrace true __libc_start_main(0x08048a50, 1, 0xbffdaf84, 0x08049a18, 0x08049a60 <unfinished ...> setlocale(6, "") = "en_GB.UTF-8" bindtextdomain("coreutils", "/usr/share/locale") = "/usr/share/locale" textdomain("coreutils") = "coreutils" __cxa_atexit(0x08048c40, 0, 0, 0xbffdaf84, 0xbffdaef8) = 0 exit(0 <unfinished ...> __fpending(0x002ae640, 0x002b0ba0, 10, 0x002b0238, 10) = 0 +++ exited (status 0) +++
Seems this is a result of my little optimization in the linker: http://sources.redhat.com/ml/binutils/2003-11/msg00258.html ltrace is not clever enough and relies on st_values of SHN_UNDEF symbols. I'll try to rework ltrace to do that differently tomorrow.
*** Bug 116565 has been marked as a duplicate of this bug. ***
Should be fixed in ltrace-0.3.32-2 in rawhide.
It still seems to be broken for "ltrace -p <pid>", i.e. I don't get any library calls reported in the output (though it does show the signals that were received by the process). This is the case both with ltrace-0.3.29-1 from FC1 and ltrace-0.3.32-2 from FC2. It used to work properly under RedHat 9, so something broke since then.
An errata has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2004-387.html