Re: /usr/bin/ld.so as a symbolic link for the dynamic loader
* 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
Reply to: