Weird ldd problem

[Chavdar Ivanov <ci4ic4%gmail.com@localhost>]

Hi,

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
/usr/local/bin
# 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
./ksh93:
        -lm.0 => /usr/lib/libm.so.0
        -lc.12 => /usr/lib/libc.so.12
        -lexecinfo.0 => /usr/lib/libexecinfo.so.0
        -lelf.2 => /usr/lib/libelf.so.2
        -lgcc_s.1 => /usr/lib/libgcc_s.so.1
# 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
sysbuild@ymir:/home/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC_KASLR
amd64

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.

Chavdar

-- 
----