I'm experimenting with ELF RUNPATH variable for dynamic dependencies. Along the way I got a copy of bash binary with changed RUNPATH, running ldd on it returns:

$ ldd ./bash 
    linux-vdso.so.1 =>  (0x00007ffe6bdf9000)
    libtinfo.so.5 (0x00007fbf8b97c000)
    libdl.so.2 (0x00007fbf8b776000)
    libc.so.6 (0x00007fbf8b3a5000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fbf8bba7000)

-- why aren't there paths to the dependencies (from my custom RUNPATH) or not found, what does it mean?

My guess would be: ldd cannot find the files, but they are in memory (numbers in parentheses are the addresses), and ldd gets to know about it somehow, via some cash-mechanism, is it correct? But then how come ldd doesn't find files? If it fails to fetch them from RUNPATH, it should proceed to standard directories, right?


Today it finds the files (so it were the cashes yesterday?):

$ cd dir_chroot2/
$ ldd ./bash
    linux-vdso.so.1 =>  (0x00007ffed3530000)
    libtinfo.so.5 => /home/.../dir_chroot2/./libtinfo.so.5 (0x00007f72c14a8000)
    libdl.so.2 => /home/.../dir_chroot2/./libdl.so.2 (0x00007f72c12a1000)
    libc.so.6 => /home/.../dir_chroot2/./libc.so.6 (0x00007f72c0ed0000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f72c16d4000)

-- but ld-linux-x86-64.so.2 is still fetched from system directory, though bash binary and all libraries above it have RUNPATH=$ORIGIN/. Why is it so? Does linux-vdso.so.1 link it somehow?



You must log in to answer this question.

Browse other questions tagged .