Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Weird ldd problem


Not really a problem, but is bugging me, I have no clue why this
happens. I used to follow the ksh93 development branch and regularly
used to build it for -current. The last one I built was circa February
2020 (${.sh.version} -> 2020.0.0-beta1-222-g8cf92b28), apparently for
NetBSD 9.99.45. It still works ok, but I am getting:
# pwd
# ls -l ksh93
-rwxr-xr-x  1 root  wheel  4582528 Feb  6  2020 ksh93
# file ksh93
ksh93: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /usr/libexec/ld.elf_so, for NetBSD
9.99.45, with debug_info, not stripped
# ldd ./ksh93
        -lm.0 => /usr/lib/
        -lc.12 => /usr/lib/
        -lexecinfo.0 => /usr/lib/
        -lelf.2 => /usr/lib/
        -lgcc_s.1 => /usr/lib/
# ldd ksh93
ldd: bad execname `ksh93' in AUX vector: No such file or directory
# uname -a
NetBSD marge.lorien.lan 9.99.86 NetBSD 9.99.86 (GENERIC_KASLR) #1: Thu
Jul 15 22:22:02 BST 2021

Basically ldd succeeds when provided a path, absolute or relative, and
fails when provided with the name only when the current directory
contains it. The same behaviour is also for shcomp, which comes from
the same build. I also examined the ktruss output from both executions
and could not see any difference right up to the point when one of
them succeeds and the other fails.

I also rebuilt the (rather old) shells/ast-ksh and it does not show
this behaviour.



Home | Main Index | Thread Index | Old Index