* 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
