Many groups want to distribute dynamically-linked ELF executables using new libc/rtld features (e.g. RELR, AArch64 PAuth), or simply because they don't want to set up a build environment with a very old version of glibc. https://www.corsix.org/content/for-want-of-a-relative-path is a nice write-up on this topic. Traditionally, this required a separate launcher script if binary patching is avoided. #!/usr/bin/env bash ORIGIN="$(dirname "$(readlink -f "$0")")" exec "$ORIGIN/libs/ld-linux-x86-64.so.2" --library-path "$ORIGIN/libs:$LD_LIBRARY_PATH" "$ORIGIN/my_executable" "$@" corsix.org notes a few drawbacks: * Execing the dynamic linker is a slightly obscure feature, which can increase the chance of hitting bugs (e.g. BZ#16381, BZ#24900). * If my_executable tries to open("/proc/self/exe") or readlink("/proc/self/exe") or similar, it'll get ld-linux-x86-64.so.2 rather than itself. * Having a launcher script is aesthetically displeasing. In addition, /proc/*/exe and proc/*/cmdline would look different and there might be weird re-exec issues. gcompat (from Adélie Linux) developers should know more caveats. --- https://github.com/rcombs/musl/tree/portable-dynamic solves the "relative interpreter problem" by building a special static-pie (ET_DSO, no PT_INTERP) that links in a custom loader (dcrt1.o, which replaces rcrt1.o). The static-pie mmap's ld-musl, adjusts auxv to point to it, and then jumps to ld-musl's entry point. (See https://www.openwall.com/lists/musl/2022/09/26/13 for some public discussions.) --- There's a growing interest in using new dynamic linker features for ELF executables. However, a solution hasn't yet been widely adopted by major libc implementations. I imagine a future where glibc supports a custom loader capable of loading the interpreter from a relative path. This would provide a clean and well-supported solution, addressing the needs of many developers.