Re: [musl] Supporting multilib LD_LIBRARY_PATHs

[Rich Felker <dalias@libc.org>]

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
libc.

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.

Rich