From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) by sourceware.org (Postfix) with ESMTPS id 2A26738493F5 for ; Wed, 17 May 2023 18:54:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2A26738493F5 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-lj1-x22c.google.com with SMTP id 38308e7fff4ca-2ac7de2b72fso11956741fa.1 for ; Wed, 17 May 2023 11:54:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684349665; x=1686941665; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:from:to:cc:subject:date:message-id:reply-to; bh=o7S//Viv+/WJUby8ywvcqKNImLg3Dfrx5j9s2ILXg2M=; b=DxwbCnUPDeyrxCX0NO/8QIyQiIuiKxcU/QOVhpnlj2/nlm2fjKAI2Y+sigY5GRMNtP Vl8YX6KqxMWsw4Mt/qyhWa8HpJHZBC4DY/7PRCyi59xnE7wTgvZr2W8MGTfep7QWmjrh aTvnvHhXYei/0l0O6jc3cWfDyslrQCwr5FKgvQ5NHNp3+g0v8kDJcaYANi1gDvOtYHzF qqfUFIg+fhzGV3AJMJKB6kODxUH+9SUYucaHAv/cwUROtHWZ3eeGoStlCrYttE4zCOGX FTYBcSOj4z2uOARIXqeofAePhusSyQ/dQw44aBh8C8r8NnymZe53bvoEQoccg3NTVyKw zGbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684349665; x=1686941665; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=o7S//Viv+/WJUby8ywvcqKNImLg3Dfrx5j9s2ILXg2M=; b=UCpj0caGpaIGsB8HRQf2mauyg7K1cu8WEx8/PEVjoorajxKrKc/HHAYrBX41Wdx8Mp w937qAIzxTguvee73otDUVxmXu42/o9Id5rvRjzFB+zuHXCfq9iMF2ilWweYK8WNTZ6I VI4Mib+zvXKV7LpvXE2iVBNj9mznoGLU9wKMteS+r4FALvX3+IVBm1fB+bL9X+X+YC9E 1IylhiXG8GngNBi/0yZCE+Tdh4P10knFi1giKFpm627yryyQHP+Mzp8pZwSCbXn0Ndrw MMrFCJJK/r+0fqlln24dsqtSokV8eE0HhABS/XhrKewJoOovzxKTBoQRPDfECNajVQ/l uDqA== X-Gm-Message-State: AC+VfDxVE3NGzN0OTLQPdwQTl9rLk1wGyxosuVfpuLNVHNLBjcvmbltj UVVDCEITG175Th5jYduwJUnTSx7KZoA= X-Google-Smtp-Source: ACHHUZ5TFe8qOZppa7xCV7SdZmgihwQONAZTwiqH4vbYiu3njo60odZ34HPFP+QMYeixeBPQ7xkwtQ== X-Received: by 2002:a2e:9495:0:b0:2a8:b579:225b with SMTP id c21-20020a2e9495000000b002a8b579225bmr9958910ljh.40.1684349664246; Wed, 17 May 2023 11:54:24 -0700 (PDT) Received: from surface-pro-6.. ([194.190.106.50]) by smtp.gmail.com with ESMTPSA id s23-20020a2e9c17000000b002ad90280503sm4052326lji.138.2023.05.17.11.54.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 May 2023 11:54:23 -0700 (PDT) From: Sergey Bugaev To: libc-alpha@sourceware.org, bug-hurd@gnu.org Subject: [RFC PATCH 0/2] On ldconfig and ld.so.cache Date: Wed, 17 May 2023 21:54:20 +0300 Message-Id: <20230517185422.71084-1-bugaevc@gmail.com> X-Mailer: git-send-email 2.40.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.1 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, having set up a very basic x86_64-gnu system to debug startup issues, I was surprised to discover that my self-built ld.so does not look for the shared libraries in /lib/x86_64-gnu/ (which is where Samuel Thibault's deb packages place them) at all. I then learned that ld.so.cache and ldconfig and ld.so.conf support is explicitly getting compiled out in the *-gnu configurations -- and that this is being done intentionally, since ldconfig is apparently considered to be a hack and a misfeature [0]. [0]: https://lists.debian.org/debian-hurd/2001/04/msg00179.html (Might this be just due to misunderstanding of what ldconfig does? It's not only about creating symlinks, it's primarily about the ld.so.cache and ld.so.conf...) This doesn't really make sense to me: surely whether ld.so.cache is a good idea or not is not tied to a particular kernel? Surely the kernel could not care less about things like the file dystem layout and how ld.so looks for shared libraries? Predicating ld.so.cache usage on whether the GNU system is running on the Linux or Hurd kernel sounds like creating pointless differences to me. Moreover, Debian GNU/Hurd, the primary Hurd-based distribution, has been shipping ld.so.cache on Hurd as a downstream patch [1] (note that more changes would be required for x86_64-gnu because of FLAG_X8664_LIB64). They don't really have a choice, it seems: with their "multiarch" filesystem layout, the shared libraries are to be located in /lib/i386-gnu/, but that is not a path that ld.so searches for libraries in! This is solved by use_ldconfig=yes, and putting /lib/i386-gnu/ into /etc/ld.so.conf.d/i386-gnu.conf, where it is then picked up by ldconfig, which finds all the libraries and bakes their paths into the cache, where ld.so then picks them up. [1]: https://salsa.debian.org/glibc-team/glibc/-/raw/sid/debian/patches/hurd-i386/local-enable-ldconfig.diff This is also another thing that suprises me: how come ldconfig does read ld.so.conf, but ld.so does not? It's not an "ldconfig.conf" after all... How is one even supposed to configure library paths with use_ldconfig=no? Anyway, maybe there are valid technical reasons to not enable ldconfig by default; this is not a hill that I'm willing to die on. But wouldn't it be nicer if it was easier to enable ldconfig downstream if desired? To that end, I tweaked ldconfig.c to not use PATH_MAX (sadly, there are still PATH_MAX usages in other places, e.g. chroot_canon.c), and moved a couple of files to stop being specific to the Linux port. I hope that both of these changes are uncontroversial. With these changes it is possible to just patch in use_ldconfig=yes downstream (is desired, of course) and get an ld.so.cache-enabled glibc on both i386-gnu and x86_64-gnu. Sergey