/usr/bin/ld.so as a symbolic link
I guess I should bring this up here as well. I've submitted a proposal to glibc upstream to install a symbolic link to the dynamic linker under /usr/bin/ld.so: [PATCH v3] elf: Install a symbolic link to ld.so as /usr/bin/ld.so <https://sourceware.org/pipermail/libc-alpha/2021-December/133952.html> This allows scripts to invoke dynamic linker features (e.g., ld.so --list-diagnostics) without hard-coding a specific path. It's still a bit rough around the edges (e.g., we can't launch binaries across architectures), but we've already fixed launching of executables that are not actually dynamically linked. I'm pretty sure OpenSUSE ships an ld.so(8) manual page already. It should be moved/linked to ld.so(1). (/usr/bin is the right directory because running ld.so does not need special privileges.) What do you think about this? Thanks, Florian
On Friday 2021-12-10 12:06, Florian Weimer wrote:
I guess I should bring this up here as well.
I've submitted a proposal to glibc upstream to install a symbolic link to the dynamic linker under /usr/bin/ld.so:
[PATCH v3] elf: Install a symbolic link to ld.so as /usr/bin/ld.so <https://sourceware.org/pipermail/libc-alpha/2021-December/133952.html>
This allows scripts to invoke dynamic linker features (e.g., ld.so --list-diagnostics) without hard-coding a specific path.
What do you think about this?
Upfront opinion, a symlink is terrible. A system may have more than one interpreter, and /usr/bin/ld.so is only one path; you will always end up with some binaries that "/usr/bin/ld.so" will refuse to run with. /usr/bin/ldd on the other hand _is_ able to handle more than one format, since ldd relies on the actual interpreter of the binary passed to it.
* Jan Engelhardt:
On Friday 2021-12-10 12:06, Florian Weimer wrote:
I guess I should bring this up here as well.
I've submitted a proposal to glibc upstream to install a symbolic link to the dynamic linker under /usr/bin/ld.so:
[PATCH v3] elf: Install a symbolic link to ld.so as /usr/bin/ld.so <https://sourceware.org/pipermail/libc-alpha/2021-December/133952.html>
This allows scripts to invoke dynamic linker features (e.g., ld.so --list-diagnostics) without hard-coding a specific path.
What do you think about this?
Upfront opinion, a symlink is terrible.
A system may have more than one interpreter, and /usr/bin/ld.so is only one path; you will always end up with some binaries that "/usr/bin/ld.so" will refuse to run with.
/usr/bin/ldd on the other hand _is_ able to handle more than one format, since ldd relies on the actual interpreter of the binary passed to it.
We are going to implement that for the ld.so relaunch as well. We've already added the ability to launch executables which are not dynamically linked. Thanks, Florian
On Friday 2021-12-10 19:52, Florian Weimer wrote:
A system may have more than one interpreter, and /usr/bin/ld.so is only one path; you will always end up with some binaries that "/usr/bin/ld.so" will refuse to run with.
/usr/bin/ldd on the other hand _is_ able to handle more than one format, since ldd relies on the actual interpreter of the binary passed to it.
We are going to implement that for the ld.so relaunch as well. We've already added the ability to launch executables which are not dynamically linked.
I was more thinking about ELFCLASS32 vs ELFCLASS64 and different EM_ types altogether.
* Jan Engelhardt:
On Friday 2021-12-10 19:52, Florian Weimer wrote:
A system may have more than one interpreter, and /usr/bin/ld.so is only one path; you will always end up with some binaries that "/usr/bin/ld.so" will refuse to run with.
/usr/bin/ldd on the other hand _is_ able to handle more than one format, since ldd relies on the actual interpreter of the binary passed to it.
We are going to implement that for the ld.so relaunch as well. We've already added the ability to launch executables which are not dynamically linked.
I was more thinking about ELFCLASS32 vs ELFCLASS64 and different EM_ types altogether.
We'll get there eventually. I gave the other example to show that it's not *only* a symbolic link. Thanks, Florian
participants (2)
-
Florian Weimer -
Jan Engelhardt