How to find out the dynamic libraries executables loads when run?
I want to find out the list of dynamic libraries a binary loads when run (With their full paths). I am using CentOS 6.0. How to do this?
9 Answers 9
You can do this with ldd command:
NAME ldd - print shared library dependencies SYNOPSIS ldd [OPTION]. FILE. DESCRIPTION ldd prints the shared libraries required by each program or shared library specified on the command line. . $ ldd /bin/ls linux-vdso.so.1 => (0x00007fff87ffe000) libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007ff0510c1000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007ff050eb9000) libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007ff050cb0000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff0508f0000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff0506ec000) /lib64/ld-linux-x86-64.so.2 (0x00007ff0512f7000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff0504ce000) libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x00007ff0502c9000) Any idea of what would be a macOS equivalent of this? No lld on darwin, it appears, nor can I find it via homebrew.
be aware that this may execute the binary. So if the binary is untrusted, it may be better to not use ldd . See man page.
To follow @PaulRooney ‘s comment: In particular, the man page suggests using objdump -p /path/to/program | grep NEEDED as an alternative to ldd if you do not trust the executable.
lddtree from pax-utils is better when you want to see the hierarchical tree of dependencies including dependencies’ dependencies; plain ldd shows only the immediate dependencies.
readelf -d $executable | grep ‘NEEDED’
Can be used if you can’t run the executable, e.g. if it was cross compiled, or if you don’t trust it:
In the usual case, ldd invokes the standard dynamic linker (see ld.so(8)) with the LD_TRACE_LOADED_OBJECTS environment variable set to 1, which causes the linker to display the library dependencies. Be aware, however, that in some circumstances, some versions of ldd may attempt to obtain the dependency information by directly executing the program. Thus, you should never employ ldd on an untrusted executable, since this may result in the execution of arbitrary code.
readelf -d /bin/ls | grep 'NEEDED' 0x0000000000000001 (NEEDED) Shared library: [libselinux.so.1] 0x0000000000000001 (NEEDED) Shared library: [libacl.so.1] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] Note that libraries can depend on other libraries, so now you need to find the dependencies.
A naive approach that often works is:
$ locate libselinux.so.1 /lib/i386-linux-gnu/libselinux.so.1 /lib/x86_64-linux-gnu/libselinux.so.1 /mnt/debootstrap/lib/x86_64-linux-gnu/libselinux.so.1 but the more precise method is to understand the ldd search path / cache. I think ldconfig is the way to go.
readelf -d /lib/x86_64-linux-gnu/libselinux.so.1 | grep 'NEEDED' 0x0000000000000001 (NEEDED) Shared library: [libpcre.so.3] 0x0000000000000001 (NEEDED) Shared library: [libdl.so.2] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x0000000000000001 (NEEDED) Shared library: [ld-linux-x86-64.so.2] /proc//maps for running processes
Mentioned by Basile, this is useful to find all the libraries currently being used by running executables. E.g.:
sudo awk '/\.so/' /proc/1/maps | sort -u shows all currently loaded dynamic dependencies of init (PID 1 ):
/lib/x86_64-linux-gnu/ld-2.23.so /lib/x86_64-linux-gnu/libapparmor.so.1.4.0 /lib/x86_64-linux-gnu/libaudit.so.1.0.0 /lib/x86_64-linux-gnu/libblkid.so.1.1.0 /lib/x86_64-linux-gnu/libc-2.23.so /lib/x86_64-linux-gnu/libcap.so.2.24 /lib/x86_64-linux-gnu/libdl-2.23.so /lib/x86_64-linux-gnu/libkmod.so.2.3.0 /lib/x86_64-linux-gnu/libmount.so.1.1.0 /lib/x86_64-linux-gnu/libpam.so.0.83.1 /lib/x86_64-linux-gnu/libpcre.so.3.13.2 /lib/x86_64-linux-gnu/libpthread-2.23.so /lib/x86_64-linux-gnu/librt-2.23.so /lib/x86_64-linux-gnu/libseccomp.so.2.2.3 /lib/x86_64-linux-gnu/libselinux.so.1 /lib/x86_64-linux-gnu/libuuid.so.1.3.0 This method also shows libraries opened with dlopen , tested with this minimal setup hacked up with a sleep(1000) on Ubuntu 18.04.
ldd and lsof show the libraries loaded either directly or at a given moment. They do not account for libraries loaded via dlopen (or discarded by dlclose ). You can get a better picture of this using strace , e.g.,
strace -e trace=open myprogram (since dlopen ultimately calls open — though you may of course have a system using different names for 64-bit opens. ).
open("/etc/ld.so.cache", O_RDONLY) = 3 open("/lib/x86_64-linux-gnu/librt.so.1", O_RDONLY) = 3 open("/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY) = 3 open("/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY) = 3 open("/usr/lib/locale/locale-archive", O_RDONLY) = 3 open("/etc/localtime", O_RDONLY) = 3 Wed Apr 12 04:56:32 EDT 2017 from which one could grep the «.so» names to just see shared objects.
Nice method. /proc/
lsof also can show you which libraries are being used for one particular process.
$ pidof nginx 6920 6919 $ lsof -p 6919|grep mem nginx 6919 root mem REG 0,64 65960 43 /lib64/libnss_files-2.12.so nginx 6919 root mem REG 0,64 19536 36 /lib64/libdl-2.12.so nginx 6919 root mem REG 0,64 10312 1875 /lib64/libfreebl3.so nginx 6919 root mem REG 0,64 1923352 38 /lib64/libc-2.12.so nginx 6919 root mem REG 0,64 88600 1034 /lib64/libz.so.1.2.3 nginx 6919 root mem REG 0,64 1967392 1927 /usr/lib64/libcrypto.so.1.0.1e nginx 6919 root mem REG 0,64 183080 1898 /lib64/libpcre.so.0.0.1 nginx 6919 root mem REG 0,64 40400 1217 /lib64/libcrypt-2.12.so nginx 6919 root mem REG 0,64 142688 77 /lib64/libpthread-2.12.so nginx 6919 root mem REG 0,64 154664 31 /lib64/ld-2.12.so For mass query:
- create a small script ( useslib ) and put in in the PATH (orspecify a full path in the command below)
#! /bin/bash ldd $1 | grep -q $2 exit $? find /usr/bin/ -executable -type f -exec useslib <> libgtk-x11-2.0 \; -print (libgtk-x11-2.0 seems to be the gtk2 lib)
For a process of pid 1234, you could also read the /proc/1234/maps (textual) pseudo-file (read proc(5). ) or use pmap(1)
This gives the virtual address space of that process, hence the files (including shared libraries, even dlopen(3)-ed one) which are memory mapped
(of course, use ps aux or pgrep(1) to find the processes running some given program)
For example, start a process: $ watch date
Get pid: $ ps -ef | grep watch
Show with full path: $ pmap -p
$ pmap 72770 72770: watch date 00005613a32c9000 20K r-x-- watch 00005613a34cd000 4K r---- watch 00005613a34ce000 4K rw--- watch 00005613a4f6a000 264K rw--- [ anon ] 00007f2f3a7d5000 204616K r---- locale-archive 00007f2f46fa7000 1748K r-x-- libc-2.27.so 00007f2f4715c000 2048K ----- libc-2.27.so 00007f2f4735c000 16K r---- libc-2.27.so 00007f2f47360000 8K rw--- libc-2.27.so 00007f2f47362000 16K rw--- [ anon ] 00007f2f47366000 12K r-x-- libdl-2.27.so 00007f2f47369000 2044K ----- libdl-2.27.so 00007f2f47568000 4K r---- libdl-2.27.so 00007f2f47569000 4K rw--- libdl-2.27.so 00007f2f4756a000 160K r-x-- libtinfo.so.6.1 00007f2f47592000 2048K ----- libtinfo.so.6.1 00007f2f47792000 16K r---- libtinfo.so.6.1 00007f2f47796000 4K rw--- libtinfo.so.6.1 00007f2f47797000 232K r-x-- libncursesw.so.6.1 00007f2f477d1000 2048K ----- libncursesw.so.6.1 00007f2f479d1000 4K r---- libncursesw.so.6.1 00007f2f479d2000 4K rw--- libncursesw.so.6.1 00007f2f479d3000 148K r-x-- ld-2.27.so 00007f2f47bdb000 20K rw--- [ anon ] 00007f2f47bf1000 28K r--s- gconv-modules.cache 00007f2f47bf8000 4K r---- ld-2.27.so 00007f2f47bf9000 4K rw--- ld-2.27.so 00007f2f47bfa000 4K rw--- [ anon ] 00007ffd39404000 136K rw--- [ stack ] 00007ffd3959b000 12K r---- [ anon ] 00007ffd3959e000 8K r-x-- [ anon ] ffffffffff600000 4K r-x-- [ anon ] total 215692K $ pmap 72770 -p 72770: watch date 00005613a32c9000 20K r-x-- /usr/bin/watch 00005613a34cd000 4K r---- /usr/bin/watch 00005613a34ce000 4K rw--- /usr/bin/watch 00005613a4f6a000 264K rw--- [ anon ] 00007f2f3a7d5000 204616K r---- /usr/lib/locale/locale-archive 00007f2f46fa7000 1748K r-x-- /usr/lib64/libc-2.27.so 00007f2f4715c000 2048K ----- /usr/lib64/libc-2.27.so 00007f2f4735c000 16K r---- /usr/lib64/libc-2.27.so 00007f2f47360000 8K rw--- /usr/lib64/libc-2.27.so 00007f2f47362000 16K rw--- [ anon ] 00007f2f47366000 12K r-x-- /usr/lib64/libdl-2.27.so 00007f2f47369000 2044K ----- /usr/lib64/libdl-2.27.so 00007f2f47568000 4K r---- /usr/lib64/libdl-2.27.so 00007f2f47569000 4K rw--- /usr/lib64/libdl-2.27.so 00007f2f4756a000 160K r-x-- /usr/lib64/libtinfo.so.6.1 00007f2f47592000 2048K ----- /usr/lib64/libtinfo.so.6.1 00007f2f47792000 16K r---- /usr/lib64/libtinfo.so.6.1 00007f2f47796000 4K rw--- /usr/lib64/libtinfo.so.6.1 00007f2f47797000 232K r-x-- /usr/lib64/libncursesw.so.6.1 00007f2f477d1000 2048K ----- /usr/lib64/libncursesw.so.6.1 00007f2f479d1000 4K r---- /usr/lib64/libncursesw.so.6.1 00007f2f479d2000 4K rw--- /usr/lib64/libncursesw.so.6.1 00007f2f479d3000 148K r-x-- /usr/lib64/ld-2.27.so 00007f2f47bdb000 20K rw--- [ anon ] 00007f2f47bf1000 28K r--s- /usr/lib64/gconv/gconv-modules.cache 00007f2f47bf8000 4K r---- /usr/lib64/ld-2.27.so 00007f2f47bf9000 4K rw--- /usr/lib64/ld-2.27.so 00007f2f47bfa000 4K rw--- [ anon ] 00007ffd39404000 136K rw--- [ stack ] 00007ffd3959b000 12K r---- [ anon ] 00007ffd3959e000 8K r-x-- [ anon ] ffffffffff600000 4K r-x-- [ anon ] total 215692K How to see the currently loaded shared objects in Linux?
You can do both with lsof . To see what processes have a library open or mapped do:
and to see what files (including shared libraries) a process has open and/or mapped, do:
That only helps if you know WHICH instance of a .so file is loaded. Is it possible to list all th e .so files actually used by an app to find the disk path to the one I need?
Another way to see what’s loaded in a process is by looking at the /proc/PID/maps file. This shows everything mapped into your address space, including shared objects mapped in.
Worked fine on my embedded ARM platform. While the BusyBox implementation of lsof did not have the needed functionality.
sudo grep libcairo.so /proc/*/maps is a nice way to explore all /proc/PID/maps mentioned by Rich at once. Sample output:
/proc/8390/maps:7f0a9afae000-7f0a9b0bc000 r-xp 00000000 fc:00 274690 /usr/lib/x86_64-linux-gnu/libcairo.so.2.11400.6 /proc/8390/maps:7f0a9b0bc000-7f0a9b2bc000 ---p 0010e000 fc:00 274690 /usr/lib/x86_64-linux-gnu/libcairo.so.2.11400.6 /proc/8390/maps:7f0a9b2bc000-7f0a9b2bf000 r--p 0010e000 fc:00 274690 /usr/lib/x86_64-linux-gnu/libcairo.so.2.11400.6 /proc/8390/maps:7f0a9b2bf000-7f0a9b2c0000 rw-p 00111000 fc:00 274690 /usr/lib/x86_64-linux-gnu/libcairo.so.2.11400.6 /proc/8466/maps:7f0a9afae000-7f0a9b0bc000 r-xp 00000000 fc:00 274690 /usr/lib/x86_64-linux-gnu/libcairo.so.2.11400.6 /proc/8466/maps:7f0a9b0bc000-7f0a9b2bc000 ---p 0010e000 fc:00 274690 /usr/lib/x86_64-linux-gnu/libcairo.so.2.11400.6 /proc/8466/maps:7f0a9b2bc000-7f0a9b2bf000 r--p 0010e000 fc:00 274690 /usr/lib/x86_64-linux-gnu/libcairo.so.2.11400.6 /proc/8466/maps:7f0a9b2bf000-7f0a9b2c0000 rw-p 00111000 fc:00 274690 /usr/lib/x86_64-linux-gnu/libcairo.so.2.11400.6 Further awk and bash-fu can refine the output further.
This method also shows libraries opened with dlopen , tested with this minimal setup hacked up with a sleep(1000) on Ubuntu 18.04.