Re: /usr/bin/ld.so as a symbolic link for the dynamic loader
* Helmut Grohne:
> 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?
Sure!
> 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?
Yes, that's what I expect as well.
> 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.
It is as architecture-independent as ldconfig or getconf. Perhaps a bit
more so than getconf.
> 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
> $
As has explained elsewhere, you need to use $LIB or just the soname (so
that ld.so searches the right paths). I expect this to work eventually:
ld.so --preload libeatmydata.so /bin/true
Even if /bin/true is an i386 program, assuming that libeatmydata1:i386
is installed. Whether ld.so is built for i386 or amd64 will not matter.
> 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.
With the patch I've posted, you'll get the ELFCLASS64 error. But I have
some ideas how to fix that eventually. Is this sufficient for now?
Thanks,
Florian
Reply to: