I thought I'd quickly write down some notes on the relocatable binary "problem" we have.
We have a need to be able to run our binaries with a different dynamic loader in a few cases which basically come down to: * uninative relocation of "native" binaries so they work on different distros via sstate * creating the relocatable SDK without needing an old "lowest common denominator" glibc * used in our tools tarballs which are effectively SDKs with different usage and without the target toolchain pieces To make this work we end up running patchelf on binaries a lot to change the interpreter. The interpreter is set in the PT_INTERP section of the ELF binary and contains a full path. A relative path also works but that is relative to CWD which isn't so useful as CWD can be anything. What I've wondered is whether we could have linux support relative paths in there with reference to the binary's own location on the filesystem? This would be similar to $ORIGIN in RPATHs and similar. If you have a build you can play around a bit with this: $ cp /usr/bin/true . $ tmp/sysroots-uninative/x86_64-linux/usr/bin/patchelf-uninative --print-interpreter ./true /lib64/ld-linux-x86-64.so.2 $ cp /lib64/ld-linux-x86-64.so.2 ../ $ tmp/sysroots-uninative/x86_64-linux/usr/bin/patchelf-uninative --set-interpreter ../ld-linux-x86-64.so.2 ./true $ ./true $ cd .. $ ./<dir>/true ./<dir>/true: No such file or directory The code that handles the interpreter is in the kernel, in fs/binfmt_elf.c:load_elf_binary(). The idea would be to add support for $ORIGIN there so that $ORIGIN is replaced with the location of the binary. Does anyone have an idea if such a change might be acceptable to the upstream kernel? Has anyone ever proposed anything like that? Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1656): https://lists.openembedded.org/g/openembedded-architecture/message/1656 Mute This Topic: https://lists.openembedded.org/mt/94756656/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
