Re: git: 99132daf6f70 - main - rc.d/ldconfig: Prepend rtld stdlib paths to ldconfig(32)_paths

On Thu, Nov 16, 2023 at 01:33:12PM +0000, Jessica Clarke wrote:
> On 16 Nov 2023, at 12:44, Dima Panov <fluffy@FreeBSD.org> wrote:
> > 
> > Moin-moin!
> > 
> > 
> > This cause some errors while running, at least on aarch64, host and poudriere jail
> > 
> > 
> > # service ldconfig restart
> > ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/compat/pkg /usr/local/lib/compat/pkg /usr/local/lib/e2fsprogs /usr/local/lib/mysql /usr/local/lib/perl5/5.38/mach/CORE /usr/local/llvm16/lib
> > ELF binary type "9" not known.
> > eval: /libexec/ld-elf32.so.1: Exec format error
> > 32-bit compatibility ldconfig path: /usr/lib32
> 
> Yeah this breaks if the kernel and/or hardware don’t support 32-bit
> compat (not uncommon on modern Arm hardware).
Interestingly, it seems to be impossible to detect that arm64 hardware
does not support executing in aarch32 mode, except trying to run a binary.
Am I missing something?

Would it be better to not register 32bit elf brand at all if hardware is
not capable?

> 
> Also, parsing the human-readable output of ld-elf.so.1 -v to determine
> the path seems wrong and fragile. Given the above problem I think this
> should just be reverted, but if we instead want to press ahead with
> something like this (with suitable handling of this case) then we
> should really have ld-elf.so.1 produce machine-readable output (which
> could just be the space-separated string) for use the rc script, not go
> mangling -v’s output. But I really don’t see the issue with putting the
> paths in the script...

Would would you qualify as machine-readable output from ld-elf.so.1 -v?
Are you against spaces in the item key names?