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 -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure