From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc2b.google.com (mail-oo1-xc2b.google.com [IPv6:2607:f8b0:4864:20::c2b]) by sourceware.org (Postfix) with ESMTPS id 1B1B53858C41 for ; Fri, 19 May 2023 13:22:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1B1B53858C41 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oo1-xc2b.google.com with SMTP id 006d021491bc7-554f1ae1fbeso445108eaf.3 for ; Fri, 19 May 2023 06:22:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684502524; x=1687094524; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=kxaB+VJnehp6IGss0LAZbz7Bg0QFJgcGMVmABIPmhis=; b=QY+tfH7VAacdKv9xk1XuibVCuoVLO/7kV+BBn+qksGpube7ZAXzfTnsupRYs96xrWA AK8bRJEZkuLbAcV03bDrH2hRR3wEdHfPFfXoWfr/BrBpOrLJXHtepagQcXbQQdIkA3Re nWoA/gvr0k2qR/uhbsyuNwdB0gi5F5ai2Nhf3xzxG8SwChkXLGPPI01gAMzjhJbArZ1N od82sQMohetgQBOuoMAV7xXfihV7NbzOmlQ6cL/cNyvj4HFb6pR9V4q3Gn5k9rN+YOgR d9pcSoH9sUcd34TXvD1jmlFBg/ebFwOIdmcqsREbC0IE0TXYqtTWY2KJ3C/R0lGESUHy 9rjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684502524; x=1687094524; h=content-transfer-encoding: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=kxaB+VJnehp6IGss0LAZbz7Bg0QFJgcGMVmABIPmhis=; b=TCULoYUettYmmyObnwAUQELENqAG4ldHhG71NS5WzTyIShOGP31kL2M7LkHKrp7Rwv Ncl6pEfR9GIWd0V93T7LNFj/dCFU4yl3r4z57FXP28i8OZu/lJCTYGgQND3DL9ujg4r7 0e2waP7NLpKohFeMiRGdTevAcNq7IPeLLraT21Xq4s9/z3bvcXZOQJDKv4cDwU8LDR1n iD4P86t3r83SL6x1et297Emcy26tJEh8vPUcJqk6oMfQLnzvdWprkYk/qMN00k+V6Dzj N74oAVgvozsaPDpu9Yp+VsQdTALPY36UL1Fl/2YeQAVVK9QTWMgupFddc/e7WL2w8cFh x+1Q== X-Gm-Message-State: AC+VfDyEv5iHOKHjT9g8MY1sSc6YVVHexT28kv0wTLDHdkEfHWCS5H3Y s9/Bfi4J2vRPqVL286vm8KAGpzWE99Cft9iPEAfiLLrW X-Google-Smtp-Source: ACHHUZ7w5/2o7dSdLj0i3B8bD5dsw7C99rprCYj6ipOx7cMn7DWW6+ugpuUUV+qDPxyuErYwlszG9cR8V0htcP3SEmg= X-Received: by 2002:a05:6808:a05:b0:38d:fa2c:b9ea with SMTP id n5-20020a0568080a0500b0038dfa2cb9eamr942108oij.47.1684502524287; Fri, 19 May 2023 06:22:04 -0700 (PDT) MIME-Version: 1.0 References: <20230517185422.71084-1-bugaevc@gmail.com> <87fs7sjygi.fsf@oldenburg3.str.redhat.com> In-Reply-To: <87fs7sjygi.fsf@oldenburg3.str.redhat.com> From: Sergey Bugaev Date: Fri, 19 May 2023 16:21:53 +0300 Message-ID: Subject: Re: [RFC PATCH 0/2] On ldconfig and ld.so.cache To: Florian Weimer , "Carlos O'Donell" Cc: bug-hurd@gnu.org, libc-alpha@sourceware.org, =?UTF-8?Q?Ludovic_Court=C3=A8s?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hello, On Fri, May 19, 2023 at 3:30=E2=80=AFPM Florian Weimer = wrote: > Debian hasn't upstreamed there multi-arch path layouts. We could > implement multi-arch ldconfig in /etc/ld.so.cache, but with the paths > that Debian currently uses, it's not easy because there's no automated > way ldconfig can recognize the relevant subdirectories. There's no > intermediate directly like =E2=80=9C=E2=80=A6/glibc-hwcaps/=E2=80=A6=E2= =80=9D that could serve as a > marker. I suppose we could look for subdirectories containing libc.so.6 > files and its variants as an approximation =E2=80=A6 Since you're taking my little rant seriously: I'm not arguing that multi-arch path layouts should be upstreamed or that ld.so should support that natively likely it does hwcaps. What I'm saying is: * There is a clear need to configure custom (downstream- or installation- specific) paths where shared libraries are to be loaded from, other than just /lib and /lib64; * /etc/ld.so.conf is the proper, well-supported, and popular way to do just that, and it is being used by many (if not all) major distros for this exact purpose -- in Debian's case, for enabling multiarch layout, among other things; * with use_ldconfig=3Dno, which is the upstream default for non-Linux, there does not seem to be a way to achieve that (without resorting to LD_LIBRARY_PATH or something like that). So if use_ldconfig=3Dno is to be kept, there should be another recommended and supported way to configure search directories. Making ld.so read ld.so.conf (parsing/globbing questions notwithstanding) might be one such way. Or maybe use_ldconfig should just get enabled everywhere :) On Fri, May 19, 2023 at 2:52=E2=80=AFPM Carlos O'Donell = wrote: > Removing configuration options and making it simple to configure and use = glibc is great > goal. I think that ldconfig should always be enabled and I don't see a do= wnside to making > `use_ldconfig=3Dyes` the default, but I think we'd have to check with Gui= x or Nix to see if > they have any custom changes there. It involves probably a slightly broad= er distro > discussion. cc'ing Ludovic; but again, why would it be convenient for Nix/Guix to have use_ldconfig enabled when building their distro with Linux but not with the Hurd? Surely they'd rather prefer it to be consistent? I don't think the reason for use_ldconfig=3Dno default is about Guix... but rather about the ideas that the original Hurd developers have had for the design of the GNU system (see also: /usr vs /). That hasn't really panned out; but I understand if the upstream defaults are still kept according to those plans. Still, using use_ldconfig=3Dyes with Hurd needs to be better supported, since that's what Hurd distros actually do in practice (I think -- well, at least Debian does), and if use_ldconfig=3Dno is to be kept supported, there has to be a way to configure library search directories without ldconfig. Sergey