[Bug 297638] ldd reports signal 13 when in pipeline
| Newsgroups | gmane.os.freebsd.bugs |
|---|---|
| Message-ID | <[email protected]/bugzilla/> |
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=297638
Bug ID: 297638
Summary: ldd reports signal 13 when in pipeline
Product: Base System
Version: 14.4-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: bin
Assignee: [email protected]
Reporter: [email protected]
I recently updated a 13.5 system to 14.4, and noticed a new weird behavior.
After a larger system update, I'm used to list all dynamic ELF binaries under
/usr/local, and then do an ldd -a on them searching for 'not found', like so:
for i in `cat /tmp/elf-files`; do ldd -a "$i" | fgrep -q 'not found' && echo
$i; done
this used to work as intended with previous FreeBSD versions, but now with 14.4
I'm getting a 'signal 13' error with files that actually reference not existing
libraries:
ldd -a /usr/local/lib32/gcc12/libgfortran.so.5.0.0 | fgrep -q 'not found'
/usr/local/lib32/gcc12/libgfortran.so.5.0.0: signal 13
with the example here:
/usr/local/lib32/gcc12/libgfortran.so.5.0.0:
libquadmath.so.0 => not found (0)
[...]
it's not limited to lib32 files:
ldd -a /usr/local/lib/compat/pam_ssh.so.5 | fgrep -q 'not found'
/usr/local/lib/compat/pam_ssh.so.5: signal 13
/usr/local/lib/compat/pam_ssh.so.5:
libssh.so.5 => not found (0)
[...]
I can work around the problem by using a temp file instead of a pipe, but I
don't think this is intended behavior...
--
You are receiving this mail because:
You are the assignee for the bug.