Re: /usr/bin/ld.so as a symbolic link for the dynamic loader
Hi Florian,
On Fri, Dec 03, 2021 at 06:29:33PM +0100, Florian Weimer wrote:
> We can add a generic ELF parser to that ld.so and use PT_INTERP, as I
> mentioned below. I think this is the way to go. Some care will be
> needed to avoid endless loops, but that should be it.
Can I ask you to go into a bit more technical detail as to how this is
supposed to work?
>From what was said, I expect that /usr/bin/ld.so is an ELF executable.
It will likely be part of libc-bin. Do you confirm?
Since libc-bin is Multi-Arch: foreign. The new ld.so really must have an
architecture-independent API. If it does not, it must not go there.
As far as I understand things, the typical use will be "ld.so
--preload somelib someprogram". Now consider an i386 ld.so, an amd64
somelib and an amd64 someprogram. Will that work with the generic ELF
parser?
At present, it does not seem to work:
$ /lib/ld-linux.so.2 --preload /usr/lib/x86_64-linux-gnu/libeatmydata.so /bin/true
/bin/true: error while loading shared libraries: /bin/true: wrong ELF class: ELFCLASS64
$
If that is what you will get from /usr/bin/ld.so, then it must not be
part of libc-bin or Multi-Arch: foreign must be dropped. The latter
likely is a non-option due to the amount of resulting breakage.
Helmut
Reply to: