[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZcM+twzp0WHa8EmL@localhost>
Date: Wed, 7 Feb 2024 09:26:31 +0100
From: i262jq@...se
To: musl@...ts.openwall.com
Subject: Re: [PATCH 0/1] ldso: continue searching if wrong
architecture is found
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
