From: Farid Zakaria <firstname.lastname@example.org> To: email@example.com Cc: "Scogland, Tom" <firstname.lastname@example.org>, email@example.com, Carlos Maltzahn <firstname.lastname@example.org> Subject: [musl] is RUNPATH being incorrectly inherited inherited? Date: Wed, 12 Jan 2022 17:29:57 -0800 [thread overview] Message-ID: <CAH4OOv7Fd=XGfYjh=ySsFYDVAZoN08YpyJ4dXr83FbPFLYVftw@mail.gmail.com> (raw) Hello, I'm observing a strange behavior and it seems to contradict what ld.so says should be the case for RUNPATH, namely I am observing that musl's dynamic linker seems to use the DT_RUNPATH of the executable when searching for entries of its children. > Using the directories specified in the DT_RUNPATH dynamic section attribute of the binary if present. Such directories are searched only to find those objects required by DT_NEEDED (direct dependencies) entries and do not apply to those objects' children, which must themselves have their own DT_RUNPATH entries. This is unlike DT_RPATH, which is applied to searches for all children in the dependency tree. I've uploaded a Makefile that you can use to follow along. First let's build the binary. It's designed to depend on two shared libraries _libx.so_ and _liby.so_; _liby.so_ also depends on _libx.so_ Note: that I make the top-level _libx.so_ an absolute path using patchelf. ``` # build it $ make CC=musl-gcc # let's inspect it to see what it looks like # here we can see the needed, including the one absolute $ patchelf --print-needed exe liby.so /home/fzakaria/code//c/libx.so libc.so # here is the RUNPATH $ patchelf --print-rpath exe $ORIGIN/b:$ORIGIN/c # an alternate query $ objdump -x ./exe | grep RUNPATH RUNPATH $ORIGIN/b:$ORIGIN/ # here is a dependent library $ patchelf --print-needed b/liby.so libx.so libc.so # liby.so has no RUNPATH objdump -x b/liby.so| grep RUNPATH ``` I would expect this *to not work* since there is no way for liby.so to discover libx.so, especially given the previous correspondence on the mailing lists on how musl does not utilize soname for the cache. However you can see that the linker is trying to resolve _libx.so_ using the RUNPATH when it is loading _liby.so_ ``` $ strace -e openat,stat,open ./exe open("/home/fzakaria/code/playground/cpp/musl-experiment/experiment-2/b/liby.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 open("/home/fzakaria/code/playground/cpp/musl-experiment/experiment-2/c/libx.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 open("/home/fzakaria/code/playground/cpp/musl-experiment/experiment-2/b/libx.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/home/fzakaria/code/playground/cpp/musl-experiment/experiment-2/c/libx.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3 24 +++ exited with 0 +++ ``` Harmen's libtree already fails to find the library. ``` $ libtree exe exe ├── libx.so [direct] └── .//b/liby.so [runpath] └── libx.so not found ┊ Paths considered ``` To me this means that the ld.so here is not respecting the description of not propagating the search paths to the children. FWIW, as per the other correspondence, if I remove part of the RUNPATH, then the binary fails to load even though _libx.so_ was already present. ``` $ patchelf --print-rpath exe $ORIGIN/b $ /exe Error loading shared library libx.so: No such file or directory (needed by /home/fzakaria/code/playground/cpp/musl-experiment/experiment-2/b/liby.so) ``` Thank you.  https://man7.org/linux/man-pages/man8/ld.so.8.html  https://gist.github.com/fzakaria/375f2c27f2db000369ec49a684ef8095  https://github.com/haampie/libtree
next reply other threads:[~2022-01-13 1:30 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-01-13 1:29 Farid Zakaria [this message] 2022-01-13 3:29 ` Rich Felker 2022-01-13 3:46 ` Farid Zakaria 2022-01-13 20:04 ` Tom Scogland
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAH4OOv7Fd=XGfYjh=ySsFYDVAZoN08YpyJ4dXr83FbPFLYVftw@mail.gmail.com' \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [musl] is RUNPATH being incorrectly inherited inherited?' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).