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
--
----
