* Paul Wise: > Florian Weimer wrote: > >> I'd like to provide an ld.so command as part of glibc. > > Will this happen in glibc upstream or just in Debian?
Upstream, and then Debian. The symbolic link would likely and up in libc-bin in Debian. >> Today, ld.so can be used to activate preloading, for example. >> Compared to LD_PRELOAD, the difference is that it's specific to one >> process, and won't be inherited by subprocesses—something is that >> exactly what is needed. > > That appears to be activated like this: > > /lib64/ld-linux-x86-64.so.2 --preload > /usr/lib/x86_64-linux-gnu/libeatmydata.so.1.3.0 /bin/ls Right, thanks for providing a concrete example. A (somewhat) portable version would look like this: ld.so --preload '/usr/$LIB/libeatmydata.so.1.3.0' /bin/sl This assumes that $LIB expands to the multi-arch subdirectory. (In upstream, it switches between lib, lib64, libx32 as needed.) >> Anyway, do you see any problems with providing /usr/bin/ld.so for use >> by skilled end users? > > It means more folks get exposed to ld.so features, which might mean > more support and feature requests for glibc upstream,. For example the > set of features provided by environment variables is different to the > set of features provided by command-line options. The intent of this change is to expose these loader features to more users and tools. This came up for --list-diagnostics, where we'd otherwise had to teach the sos tool (and others) how to find the loader path. Thanks, Florian