/usr/bin/ld.so as a symbolic link for the dynamic loader
I'd like to provide an ld.so command as part of glibc. 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.
There is also some useful diagnostic output in --help,
--list-diagnostics.
Having ld.so as a real command makes the name architecture-agnostic.
This discourages from hard-coding non-portable paths such as
/lib64/ld-linux-x86-64.so.2 or even (the non-ABI-compliant)
/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 in scripts that require
specific functionality offered by such an explicit loader invocation.
I thought that commands with file extensions might be Policy violation.
Policy actually talks about file extensions for programs installed in
/usr/bin—but only for scripts. So it's technically okay. And today,
there's already an ld.so manual page, although it's in section 8 and 1.
(I think /usr/bin is still appropriate because running ld.so does not
require special privileges.)
The initial implementation will be just a symbolic link. This means
that multi-arch support will be missing: the amd64 loader will not be
able to redirect execution to the s390x loader. In principle, it should
be possible to find PT_INTERP with a generic ELF parser and redirect to
that, but that's vaporware at present. I don't know yet if it will be
possible to implement this without some knowledge of Debian's multi-arch
support in the loader. Upstream doesn't have those features (we only
support /usr/lib vs /usr/lib64 and some minor variants of that), so
integration might be lacking.
If someone wants to upstream the multi-arch patches, that would be
great. glibc now accepts submissions under DCO, so copyright assignment
should no longer be an obstacle.
Anyway, do you see any problems with providing /usr/bin/ld.so for use by
skilled end users?
Thanks,
Florian
Reply to: