mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <>
To: Colin Cross <>
Subject: Re: [musl] Supporting multilib LD_LIBRARY_PATHs
Date: Tue, 7 Feb 2023 19:49:07 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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.

If your goal is to change the default path that gets searched for all
programs, the right place is /etc/ld-musl-$ARCH.path. It's already
per-arch and non-conflicting with a potentially coexisting alternate

Please don't take any of this as a rejection of the proposed change. I
think it's probably okay, and probably an improvement on the usability
of it. But I do think the apparent need suggests that .path files were
likely a better solution to the problem at hand.


  reply	other threads:[~2023-02-08  0:49 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 [this message]
2023-02-08  1:36   ` Alexey Izbyshev
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).