From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24393 invoked from network); 8 Feb 2023 00:49:23 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 8 Feb 2023 00:49:23 -0000 Received: (qmail 1385 invoked by uid 550); 8 Feb 2023 00:49:20 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 1347 invoked from network); 8 Feb 2023 00:49:19 -0000 Date: Tue, 7 Feb 2023 19:49:07 -0500 From: Rich Felker To: Colin Cross Cc: musl@lists.openwall.com Message-ID: <20230208004906.GR4163@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Supporting multilib LD_LIBRARY_PATHs 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