Re: [musl] [PATCH 0/1] ldso: continue searching if wrong architecture is found

[enh <enh@google.com>]

On Wed, Feb 7, 2024 at 9:17 AM Thorsten Glaser <tg@mirbsd.de> wrote:
>
> enh dixit:
>
> >helpful in catching cases where people had libraries for the wrong
> >_architecture_, not just the wrong bitness. "with enough users, all
> >errors are common" :-) )
>
> But are these errors?

well, that's the philosophical question that brings us here today :-)

> On Debian, with Multi-Arch and qemu-user and whatnot, that would not
> even be unusual, if perhaps not common.
>
> I’m mildly tending towards ignoring objects that are not valid
> shared objects of the current architecture and ABI.

i think the strongest argument we heard in favor of ignoring this is
the "what about a 64-bit process that exec()s a 32-bit process, or
vice versa?". on Android that's probably also a bug. having the
_libraries_ for two bitnesses isn't unusual (or "wasn't" anyway --- in
2024 we're getting to the point where low-end is 32-only and the rest
64-only, but 32/64 was common for the last decade), but _executables_
(other than the two zygotes) was probably a bug, and encouraging apps
not to have 64-bit helpers in addition to 64-bit libraries was only
going to cause us trouble for the inevitable _switch_ to 64-only when
arm64 hardware dropped 32-bit support. moreover, getting a _correct_
value of LD_LIBRARY_PATH on Android is non-trivial anyway, given the
split between system and vendor code.

but, yeah, if you're mainly thinking about x86-64, that doesn't seem
likely to ever drop 32-bit support, so your "transition" might be
something you never come out of.

> bye,
> //mirabilos
> --
> Support mksh as /bin/sh and RoQA dash NOW!
> ‣ src:bash (429 (458) bugs: 0 RC, 295 (315) I&N, 134 (143) M&W, 0 F&P) + 209
> ‣ src:dash (90 (104) bugs: 0 RC, 51 (54) I&N, 39 (50) M&W, 0 F&P) + 62 ubu
> ‣ src:mksh (1 bug: 0 RC, 0 I&N, 1 M&W, 0 F&P)
> dash has two RC bugs they just closed because they don’t care about quality…