Re: Weird ldd problem
In article , Chavdar Ivanov wrote: >I have to read more to understand it though... It is a kernel issue. The kernel is passing an executable pathname that is not an absolute path and RTLD correctly refuses to honor $ORIGIN. christos
Re: Weird ldd problem
On Sun, 18 Jul 2021, Chavdar Ivanov wrote: The main difference is indeed ... (RPATH) Library rpath: [$ORIGIN/:$ORIGIN/../../lib/libast:$ORIGIN/cmds:$ORIGIN/../../lib/libdll] I have to read more to understand it though... $ORIGIN? That's yet another way to locate shared libraries. At run-time, $ORIGIN is replaced with the pathname of the executable, and libraries are searched for in the new path that results. Let's say you link a program like this: cc -o foo foo.c -Wl,-rpath='$ORIGIN/../lib' Then, if the executable is installed in /opt/X/bin, the search path becomes `/opt/X/bin/../lib'. Typically used by large commercial programs which the user could install into any location, and they don't want the user to muck about adjusting paths in /etc/ld.so.conf or LD_LIBRARY_PATH. Incidentally, NetBSD's ld.elf_so seems overly sensitive about this. I always thought that $ORIGIN always expanded to an absolute path rather than a relative one. At least, that's how it is on Linux and FreeBSD. Have the linker experts look at this, then file a PR if warranted. -RVP
Re: Weird ldd problem
On Sun, 18 Jul 2021, Chavdar Ivanov wrote:
# 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
That's coming from the run-time linker:
function expand() in src/libexec/ld.elf_so/expand.c when it tries
to expand $ORIGIN. You can create such a binary yourself like this:
---
$ cat foo.c
#include
int
main(int argc, char* argv[])
{
printf("%s\n", *argv);
return 0;
}
$ cc -o foo foo.c -Wl,-rpath='$ORIGIN'
$ ldd ./foo
./foo:
-lc.12 => /usr/lib/libc.so.12
$ ldd foo
ldd: bad execname `foo' in AUX vector: Undefined error: 0
$ readelf -d foo
Dynamic section at offset 0xbb8 contains 18 entries:
TagType Name/Value
0x0001 (NEEDED) Shared library: [libc.so.12]
0x000f (RPATH) Library rpath: [$ORIGIN]
0x000c (INIT) 0x400530
0x000d (FINI) 0x4009b0
0x0004 (HASH) 0x400210
0x0005 (STRTAB) 0x4003c8
0x0006 (SYMTAB) 0x400260
0x000a (STRSZ) 158 (bytes)
0x000b (SYMENT) 24 (bytes)
0x0015 (DEBUG) 0x0
0x0003 (PLTGOT) 0x600d48
0x0002 (PLTRELSZ) 120 (bytes)
0x0014 (PLTREL) RELA
0x0017 (JMPREL) 0x4004b0
0x0007 (RELA) 0x400468
0x0008 (RELASZ) 72 (bytes)
0x0009 (RELAENT)24 (bytes)
0x (NULL) 0x0
---
Do a `readelf -d' on both ksh93s. You'll see the difference.
-RVP
Re: Weird ldd problem
On Sun, 18 Jul 2021 at 10:26, RVP wrote:
>
> On Sun, 18 Jul 2021, Chavdar Ivanov wrote:
>
> > # 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
> >
>
> That's coming from the run-time linker:
>
> function expand() in src/libexec/ld.elf_so/expand.c when it tries
> to expand $ORIGIN. You can create such a binary yourself like this:
>
> ---
> $ cat foo.c
> #include
>
> int
> main(int argc, char* argv[])
> {
> printf("%s\n", *argv);
> return 0;
> }
> $ cc -o foo foo.c -Wl,-rpath='$ORIGIN'
> $ ldd ./foo
> ./foo:
> -lc.12 => /usr/lib/libc.so.12
> $ ldd foo
> ldd: bad execname `foo' in AUX vector: Undefined error: 0
> $ readelf -d foo
>
> Dynamic section at offset 0xbb8 contains 18 entries:
>TagType Name/Value
> 0x0001 (NEEDED) Shared library: [libc.so.12]
> 0x000f (RPATH) Library rpath: [$ORIGIN]
> 0x000c (INIT) 0x400530
> 0x000d (FINI) 0x4009b0
> 0x0004 (HASH) 0x400210
> 0x0005 (STRTAB) 0x4003c8
> 0x0006 (SYMTAB) 0x400260
> 0x000a (STRSZ) 158 (bytes)
> 0x000b (SYMENT) 24 (bytes)
> 0x0015 (DEBUG) 0x0
> 0x0003 (PLTGOT) 0x600d48
> 0x0002 (PLTRELSZ) 120 (bytes)
> 0x0014 (PLTREL) RELA
> 0x0017 (JMPREL) 0x4004b0
> 0x0007 (RELA) 0x400468
> 0x0008 (RELASZ) 72 (bytes)
> 0x0009 (RELAENT)24 (bytes)
> 0x (NULL) 0x0
> ---
>
> Do a `readelf -d' on both ksh93s. You'll see the difference.
The main difference is indeed
... (RPATH) Library rpath:
[$ORIGIN/:$ORIGIN/../../lib/libast:$ORIGIN/cmds:$ORIGIN/../../lib/libdll]
I have to read more to understand it though...
>
> -RVP
>
Thanks,
Chavdar
--
Weird ldd problem
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
--
