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

[enh <enh@google.com>]

On Wed, Feb 7, 2024 at 12:29 AM <i262jq@0w.se> wrote:
>
> On Tue, Feb 06, 2024 at 05:22:42PM -0800, Markus Mayer wrote:
> > script of the app will set LD_LIBRARY_PATH to the directory containing
> [...]
> > What we have discovered is that 64-bit applications launched by the
> > 32-bit app will fail due to a shared library mismatch. The 32-bit app
>
> This is a known problem with the LD_LIBRARY_PATH semantics.
>
> > The solution:
> >
> > The shared library loader needs to keep searching the rest of the
> > library search path if the library it found in LD_LIBRARY_PATH could not
> > be mapped. If the library loader does this, everything will work fine as
> > long as the library resides on the system in a well known path.
>
> This would possibly solve your particular case, but not the main trouble
> inherent in LD_LIBRARY_PATH (a child process mapping an unexpected
> library instance).
>
> A well working solution is to wrap each application binary in a starter
> which explicitly runs the dynamic loader with the argument
>  --library-path <where the libraries are>
> (then the path to the application binary and the arguments, of course)
>
> This solves the problems reliably and is well proven.

(in particular: this is the way Android went... we originally did
support just ignoring invalid entries on the path, but that was
confusing and error-prone so we switched to a clear "your library path
is wrong for this binary" error. surprisingly [to me] it was also
helpful in catching cases where people had libraries for the wrong
_architecture_, not just the wrong bitness. "with enough users, all
errors are common" :-) )

> My 2c
> /i262jq