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=-2.9 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,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 5D76E2B875 for ; Wed, 7 Feb 2024 17:45:44 +0100 (CET) Received: (qmail 30355 invoked by uid 550); 7 Feb 2024 16:42:57 -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 30323 invoked from network); 7 Feb 2024 16:42:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1707324330; x=1707929130; darn=lists.openwall.com; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Dj7Tlim9+7rFO9bqEbqh0igSf1uxzSkTC7pNaB1gdOk=; b=Lpu5JOmpZKGA4hwPcaixiBD1JTZuMYwzg3GNiCrvMNJF6gqRtYcryJteDrMgRitvy8 LhUTW9cTYnTEWs5MUpdfhYnEO1JZE8pNSfKwzMs5sD92/gTGOQcu3KKM67l4/NyiFIbN 7k7c65T47MN/ktVwh1BleSD1S4zGWgm1buGwN5DE6GX0q688VtjgmT7VZybiL6mXiFkT uZhVlkKUIfCGEgf0ejSLWEInstRaJVmF75P+nCuPWA37Hw/PUn+fSpLUM9C4U+0tKAkF uN5ePPyfZMSuoBnGwwZ/aYtIp/yFGHOjF1w3kckZ6uJr7vCSiH71r2Gge34xLiMA8TRt LbKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707324330; x=1707929130; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Dj7Tlim9+7rFO9bqEbqh0igSf1uxzSkTC7pNaB1gdOk=; b=Hqnt7RrTd96u9fa2vGy+GGmGQXK0gn8GNr7iHfKcDrjEti00ULbAlcSgRhULVcgpkA CUKnD9brk9Q8177wBkqUAII2Aot5+Y0z+nUYKKi/GFiz70CPJYmhog5/9TqMlCJ1zSen zqUpyGBLX90HzEaNJG0L2C8TU86dCJ4anVceVf9JlR7EgogZ5k5SLXaCarznZo115hGB rfR4q1uOySEw6TOKELrVLYirlHJnIFnRKWpFVx7MPydcDtiv+Wf3/V6082OXDssPxS+Z pOr9Vne59rn2xyy0A3SHTflcOX56D5hYJv4z4ZBQpTnVQhgLFyMDe8EQbxjokzDDBSHK uXzA== X-Gm-Message-State: AOJu0YykjpAkmukwwi4+T8eJ/AZpaO61Mh80Xn6XoL1vPvgpqKh7V2vy kMIxmJ165FqxLwbPfafuGZ424/g9CgSr+qQSq2p9tft4Y1krw4HTSToNpIAb654nT2WlU3l/Djr C1C1UsSU2ChZjs4wt4boUf5dPColywhnNYkTEiiCwfnqg2qjTU//e X-Google-Smtp-Source: AGHT+IHo6vx07lceBZRS/0ogCsIPneNPfM2Mi4q5SHAC8VN7Fd8xXrG2rEtoVZ8QP/UMKZNCu5rmHKUnblmJTUUGOkc= X-Received: by 2002:a05:6122:4d03:b0:4c0:328d:c4f9 with SMTP id fi3-20020a0561224d0300b004c0328dc4f9mr3143036vkb.0.1707324330246; Wed, 07 Feb 2024 08:45:30 -0800 (PST) MIME-Version: 1.0 References: <20240207012247.1121273-1-mmayer@broadcom.com> In-Reply-To: From: enh Date: Wed, 7 Feb 2024 08:45:19 -0800 Message-ID: To: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] [PATCH 0/1] ldso: continue searching if wrong architecture is found On Wed, Feb 7, 2024 at 12:29=E2=80=AFAM wrote: > > 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 no= t > > be mapped. If the library loader does this, everything will work fine a= s > > 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. (in particular: this is the way Android went... we originally did support just ignoring invalid entries on the path, but that was confusing and error-prone so we switched to a clear "your library path is wrong for this binary" error. surprisingly [to me] it was also helpful in catching cases where people had libraries for the wrong _architecture_, not just the wrong bitness. "with enough users, all errors are common" :-) ) > My 2c > /i262jq