On Thursday, December 2, 2021 7:38:29 PM CET Florian Weimer wrote:
> 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 (instead of just a manual page) makes the
> name architecture-agnostic. This discourages from hard-coding
> non-portable paths such as /lib64/ld-linux-x86-64.so.2 in scripts that
> require specific functionality offered by such an explicit loader
> invocation.
>
> Do you see a problem with installing /usr/bin/ld.so?
>
> It would go into glibc-common on x86-64, and the initial version won't
> be able to launch 32-bit programs (“wrong ELF class: ELFCLASS32”).
>
> Thanks,
> Florian
I love this idea. As it is now, we have to to hard-wire the real path to
ld.so at multiple places in csexec and query it back in the related wrapper
scripts:
https://github.com/csutils/cswrap/wiki/csexec
If there was a standard path to the dynamic linker (for the native arch),
we could simplify our tooling that uses it explicitly.
Kamil
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
