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 Tool for Library Dependency
I’m looking for the tool / command on Unix platform to detect the library dependencies of the .so and .o files. I have already used the ldd / nm / truss , but I don’t know the proper approach to detect library dependencies.
1 Answer 1
It depends on what exactly is meant by «detect library dependencies».
The ldd command works on shared libraries, not just on executables. It will display the dependencies of a shared library declared when the library was built:
$ ldd /usr/lib/libgtk-3.so linux-vdso.so.1 (0x00007ffff8fff000) libgdk-3.so.0 => /usr/lib/libgdk-3.so.0 (0x00007f43fcf47000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00007f43fcd43000) libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x00007f43fcb36000) libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f43fc7fc000) . A library can have undefined symbols that are obtained by linking with further libraries not declared as dependencies. You can use objdump -T or nm -D to show the dynamic symbols — undefined symbols (those that should come from other libraries) will show up as *UND* :
$ objdump -T /usr/lib/libgtk-3.so | head /usr/lib/libgtk-3.so: file format elf64-x86-64 DYNAMIC SYMBOL TABLE: 0000000000066e38 l d .init 0000000000000000 .init 0000000000000000 DF *UND* 0000000000000000 g_param_spec_object 0000000000000000 DF *UND* 0000000000000000 g_utf8_validate 0000000000000000 DF *UND* 0000000000000000 g_date_get_month 0000000000000000 DF *UND* 0000000000000000 g_bookmark_file_get_visited 0000000000000000 DF *UND* 0000000000000000 g_value_get_float From these symbol names it should be possible to deduce undeclared library dependencies.
Libraries that use pkg-config or similar configuration mechanism sometimes fail to declare their dependencies at build-time, but declare the dependencies to pkg-config , relying on the library users to use the tool to get the dependencies. pkg-config —libs will list the dependencies in the format understood by the compiler:
$ pkg-config --libs gtk+-3.0 -lgtk-3 -lgdk-3 -latk-1.0 -lgio-2.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject -lpango-1.0 -lcairo -lgobject-2.0 -lglib-2.0