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