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

[Florian Weimer]

* Sergey Bugaev via Libc-alpha:

> 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?

The cache isn't really a cache, it's required for correct operation.

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 …

Multi-arch /etc/ld.so.cache needs some new on-disk data structures.

Thanks,
Florian