On 5/17/23 14:54, Sergey Bugaev via Libc-alpha wrote: > 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...) > > <rant> > > 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.
I agree that we should reduce differences here, and that the data files used by the loader should be more-or-less the same across kernels. Keep in mind that ld.so.cache is not actually a cache, but a data file that contains the pre-processed contents of /etc/ld.so.conf* in a format that can be easily loaded by the dynamic loader without having a parser (glob included) in the early startup code. Deleting the cache can break a system, and perhaps this is what some developers have objected to and called "a hack." I filed a bug for this in 2017 to capture the issue: ld.so's cache should live in /var/cache, and support cache deletion. https://sourceware.org/bugzilla/show_bug.cgi?id=22359 > 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. >From 2018 we have this: Implement multiarch ldconfig https://sourceware.org/bugzilla/show_bug.cgi?id=22825 > [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 file /etc/ld.so.cache is not a cache, it is a data file used by the dynamic loader. The data file is generated by ldconfig as it parses /etc/ld.so.conf*. The only other way to configure library paths with `use_ldconfig=` is to use LD_PRELOAD, LD_LIBRARY_PATH, DT_RPATH, or DT_RUNPATH. > </rant> > > 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. 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. -- Cheers, Carlos.
