mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Alexey Izbyshev <>
Cc: Colin Cross <>
Subject: Re: [musl] Supporting multilib LD_LIBRARY_PATHs
Date: Wed, 08 Feb 2023 04:36:23 +0300	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 2023-02-08 03:49, Rich Felker wrote:
> On Tue, Feb 07, 2023 at 02:58:37PM -0800, Colin Cross wrote:
>> I'm hitting an issue where some test infrastructure is setting
>> LD_LIBRARY_PATH to a list that contains both 32-bit and 64-bit
>> libraries because it is unsure whether the code under test is going to
>> execute 32-bit or 64-bit processes or both.  When using musl the
>> dynamic loader takes the first library with a matching name and then
>> fails to load it if it is for the wrong elf class.
>> The attached patch verifies the elf machine and class when searching
>> the path list, continuing the search if a valid elf header with an
>> incorrect machine or class is found.
> While it requires some consideration to ensure that this yields safe &
> consistent behavior, I think it at least admits that; I haven't
> checked the actual code, but conceptually, it should be equivalent to
> treating finding a mismatched-arch library as a conclusive result
> whose behavior is searching the remainder of the search path.
> I'm a little bit skeptical of the motivation though. In general, it's
> not safe to just set LD_LIBRARY_PATH and run programs that might
> invoke other programs, since the math might contain outdated or
> mismatched libraries relative to what those other programs might want.
> On a system with multiple libcs present, the libraries found could
> even be for the wrong one. Really, LD_LIBRARY_PATH should just be set
> for invoking a single program (or family of binaries) that ships with
> its own versions of libraries or when you're overriding certain
> libraries for it, etc. This is contrary to how the environment works,
> and one reason it's probably better to use ldso --library-path=...
> rather than LD_LIBRARY_PATH when overriding libraries for a particular
> program invocation.
It's sometimes convenient to use LD_PRELOAD in conjunction with 
LD_LIBRARY_PATH to override libc functions in a specific process tree 
containing binaries for different architectures, e.g. 32-bit/64-bit on 
x86 systems or native/foreign (run via qemu-user). I don't know how to 
achieve that with current musl other than by overriding 
exec*/posix_spawn functions and manually checking the architecture of 
the binary (and not forgetting to process "#!" for scripts), so I'd be 
glad to see the proposed functionality in musl.

In general, it would still not work on systems with multiple libcs, but 
I'd expect the mixed-libc case to be much rarer than the mixed-arch one.


  reply	other threads:[~2023-02-08  1:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-07 22:58 Colin Cross
2023-02-08  0:49 ` Rich Felker
2023-02-08  1:36   ` Alexey Izbyshev [this message]
2023-02-08  5:28   ` Colin Cross
2023-02-08 21:14     ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).