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=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 25587 invoked from network); 8 Feb 2023 05:28:38 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 8 Feb 2023 05:28:38 -0000 Received: (qmail 11974 invoked by uid 550); 8 Feb 2023 05:28:34 -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 11935 invoked from network); 8 Feb 2023 05:28:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=PuKyEG2aYNx6j8BzMY/JRkoUAma+ApWkUthUGK9F3wM=; b=Ghcjbnyy7JOjgiTV43eMvHJ82ZGZtEi0TvYq2YEGEd+zI6YES3zI7Z8vKayqSaBc92 6wzSxHeoWAFaNE4LNz2UZCYULX6E5v0yUAHuCNdjYA42RQ87szGhwjMOtK9z8sJEpRy3 38Lyg46j9gehhVD6GyLW7Aozb3kxIpE5K8PUqA26HNBc1gYOQsZCGqr6LSuUyTkEn5aP KfykrlrI6zdqD04qsElcUhshe+VRlCZuu1xRIOUGzZVzroI0ows3MiJUlD4sbGS6aoq3 qzde4m4cWk9y/ZwvthPazUrP5hyuHU5K7jvAcghyv5D5aORof58e0rOikZhTG/t1OvOM 3wwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc: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=PuKyEG2aYNx6j8BzMY/JRkoUAma+ApWkUthUGK9F3wM=; b=hlxCmg3OS3ohq3ghS9CvK0A0vrKyUYv3g3n/oHvOxhlxpZ6X45uVrH3XerOFSUZxVU V5ahDIJmjXaUu3BeMLj6kyk1eQSlgOiY+oDZOgaqrO7XATi4sjlzry/h+zJuCIZI7aAP dqZJ3Ol6Q3YyATDcsw1eGKGseDkNU87QUyAV75Bg/mjILlJZEq+jfcaM+DPi1fSH7Q+D 8ksmvm7hSw8U++WA0UI9sycbI1BDto2lq91spHiO4vjhlBOgfni1kApXbf+K0VKrbwez +ODRSRbPetuzX3xAWrLYrw8m8hc+wZm6RM5V/okQSioM/XRbInOTpcWdckZpR/V51MDK ES8Q== X-Gm-Message-State: AO0yUKVOGc0W+RRPHWV086LJ39VKcvmZIhJZz5lUc+HqG7wWOGVQdUpn BKTxdv/pfrZMUMinYdW20MqzXdpAxPB2HUAfIB6K/Q== X-Google-Smtp-Source: AK7set90y0XO2R5Y8i2+MAOgBzjus8+qhOF/M3mmtBVWokrLx5Hbyj7GfBm96lp6GuepEsGb86XztZRVjHkip/mozZs= X-Received: by 2002:a05:6102:3b0b:b0:411:a873:57bb with SMTP id x11-20020a0561023b0b00b00411a87357bbmr1278816vsu.25.1675834100924; Tue, 07 Feb 2023 21:28:20 -0800 (PST) MIME-Version: 1.0 References: <20230208004906.GR4163@brightrain.aerifal.cx> In-Reply-To: <20230208004906.GR4163@brightrain.aerifal.cx> From: Colin Cross Date: Tue, 7 Feb 2023 21:28:10 -0800 Message-ID: To: Rich Felker Cc: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [musl] Supporting multilib LD_LIBRARY_PATHs On Tue, Feb 7, 2023 at 4:49 PM Rich Felker wrote: > > 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. We intend to distribute binaries built against musl using relinterp (or Xcrt1 if that gets merged), which finds the dynamic loader relative to the binary. These will be used on end user systems that normally use glibc. The testing environment is taking a hermetic bundle of musl and the test binaries built against musl, and are intended to be hermetic so they shouldn't be executing anything that would use a non-musl libc. Normally the binaries use relative DT_RUNPATH entries to find their libraries, but some older branches don't have correct DT_RUNPATH entries for the layout of the tests vs. their libraries, and so the test infrastructure uses LD_LIBRARY_PATH. I'd like to remove the use of LD_LIBRARY_PATH at least in the cases that have correct DT_RUNPATH entries, but this still seemed like a reasonable enhancement to musl and will solve my immediate problems. > 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. We need to search for libraries relative to the binary, but if I'm reading the code correctly relative paths in ../etc/ld-musl-$ARCH.path would search relative to PWD. The test infrastructure could write a custom ../etc/ld-musl-$ARCH.path with absolute paths to wherever it happened to install the bundle, but currently it is agnostic to the details of the libc included in the bundle, and LD_LIBRARY_PATH works for both glibc and musl (after this patch). > 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