Re: [RFC PATCH 0/2] On ldconfig and ld.so.cache

[Sergey Bugaev]

Hello,

On Fri, May 19, 2023 at 3:30 PM Florian Weimer <fweimer@redhat.com> 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 “…/glibc-hwcaps/…” that could serve as a
> marker.  I suppose we could look for subdirectories containing libc.so.6
> files and its variants as an approximation …

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=no, 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=no 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 PM Carlos O'Donell <carlos@redhat.com> 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 
> downside to making
> `use_ldconfig=yes` the default, but I think we'd have to check with Guix or 
> Nix to see if
> they have any custom changes there. It involves probably a slightly broader 
> 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=no 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=yes 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=no is to be kept supported, there has to be a way to
configure library search directories without ldconfig.

Sergey