From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 732D228CDF for ; Wed, 7 Feb 2024 09:29:17 +0100 (CET) Received: (qmail 7746 invoked by uid 550); 7 Feb 2024 08:26:31 -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 7711 invoked from network); 7 Feb 2024 08:26:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=x.fripost.org; h= in-reply-to:content-disposition:content-type:content-type :mime-version:references:message-id:subject:subject:from:from :date:date; s=9df9cdc7e101629b5003b587945afa70; t=1707294544; x= 1709108945; bh=WTPgzQtJgaYH5I17uG0R6Z+8e2aNJ2ikSykyS3fgwik=; b=C jaVxRK2lwKKxx6TWmvRPux9sgsVMronlw7pJvfKOXxiq5S9UzQ/DNNyVPHehA8QD L+qbTa0UMXVBwKZFwKioBnlBH5e57Ar8V0U+kQzriVRa/vMMvJ0620n8zCJzqEAx BnPb4WE5jriQxsBCeLpzKQolrkgrTOI1QsTZK1/AFBAH2vztVKTfm/ua/2oU2NSv qjFwrPgKp2Kl5S90cG0lzazHu3thzcYvO2rJ271HGT5VWm9muxls1cG3RxQYvMcl +aLUTknX+DVLwE4iF4bM1kkDYWP+abAyKx6b/SlZ2wYnZnLduXgR3NygdqSPQvGf f9QJdfaaLMyjjovGs5o0A== X-Virus-Scanned: Debian amavisd-new at fripost.org Date: Wed, 7 Feb 2024 09:26:31 +0100 From: i262jq@0w.se To: musl@lists.openwall.com Message-ID: References: <20240207012247.1121273-1-mmayer@broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240207012247.1121273-1-mmayer@broadcom.com> Subject: Re: [musl] [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 (then the path to the application binary and the arguments, of course) This solves the problems reliably and is well proven. My 2c /i262jq