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

[i262jq@0w.se]

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.

My 2c
/i262jq