Hello, On Fri, May 19, 2023 at 3:30 PM Florian Weimer <fwei...@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 <car...@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
