How to show all shared libraries used by executables in Linux?
I’d like to know which libraries are used by executables on my system. More specifically, I’d like to rank which libraries are used the most, along with the binaries that use them. How can I do this?
14 Answers 14
- Use ldd to list shared libraries for each executable.
- Cleanup the output
- Sort, compute counts, sort by count
To find the answer for all executables in the «/bin» directory:
find /bin -type f -perm /a+x -exec ldd <> \; \ | grep so \ | sed -e '/^[^\t]/ d' \ | sed -e 's/\t//' \ | sed -e 's/.*=..//' \ | sed -e 's/ (0.*)//' \ | sort \ | uniq -c \ | sort -n Change «/bin» above to «/» to search all directories.
Output (for just the /bin directory) will look something like this:
1 /lib64/libexpat.so.0 1 /lib64/libgcc_s.so.1 1 /lib64/libnsl.so.1 1 /lib64/libpcre.so.0 1 /lib64/libproc-3.2.7.so 1 /usr/lib64/libbeecrypt.so.6 1 /usr/lib64/libbz2.so.1 1 /usr/lib64/libelf.so.1 1 /usr/lib64/libpopt.so.0 1 /usr/lib64/librpm-4.4.so 1 /usr/lib64/librpmdb-4.4.so 1 /usr/lib64/librpmio-4.4.so 1 /usr/lib64/libsqlite3.so.0 1 /usr/lib64/libstdc++.so.6 1 /usr/lib64/libz.so.1 2 /lib64/libasound.so.2 2 /lib64/libblkid.so.1 2 /lib64/libdevmapper.so.1.02 2 /lib64/libpam_misc.so.0 2 /lib64/libpam.so.0 2 /lib64/libuuid.so.1 3 /lib64/libaudit.so.0 3 /lib64/libcrypt.so.1 3 /lib64/libdbus-1.so.3 4 /lib64/libresolv.so.2 4 /lib64/libtermcap.so.2 5 /lib64/libacl.so.1 5 /lib64/libattr.so.1 5 /lib64/libcap.so.1 6 /lib64/librt.so.1 7 /lib64/libm.so.6 9 /lib64/libpthread.so.0 13 /lib64/libselinux.so.1 13 /lib64/libsepol.so.1 22 /lib64/libdl.so.2 83 /lib64/ld-linux-x86-64.so.2 83 /lib64/libc.so.6 This is a great answer (I’ve up-voted it) but can you explain the «grep -P ‘\t.*so'» command? According to man, this interprets the pattern as a perl regexp, but my version of grep doesn’t support it (man indicates this is a general issue). What bit of the regexp is perl-specific?
Be aware that ldd actually runs the executable with a special environment variable, and the Linux dynamic linker recognizes this flag and just outputs the libraries rather than running the executable. Look at the source to ldd ; on my system, it’s a bash script. If the executable is statically linked and uses syscalls, and specifies a different loader, it can do arbitrary evil things. So don’t use ldd on an executable you don’t trust.
‘ldd’ doesn’t work for me on cross-compiled binaries. The question is about finding the libraries used by programs on the current system (that would be native programs, as phrased). This is a good answer for that. However, I thought I’d mention that you need to use something else if looking for the shared libs for programs for a different system (‘readelf’ mentioned in another answer, worked for me)
I didn’t have ldd on my ARM toolchain so I used objdump:
objdump -p /usr/bin/python: Dynamic Section: NEEDED libpthread.so.0 NEEDED libdl.so.2 NEEDED libutil.so.1 NEEDED libssl.so.1.0.0 NEEDED libcrypto.so.1.0.0 NEEDED libz.so.1 NEEDED libm.so.6 NEEDED libc.so.6 INIT 0x0000000000416a98 FINI 0x000000000053c058 GNU_HASH 0x0000000000400298 STRTAB 0x000000000040c858 SYMTAB 0x0000000000402aa8 STRSZ 0x0000000000006cdb SYMENT 0x0000000000000018 DEBUG 0x0000000000000000 PLTGOT 0x0000000000832fe8 PLTRELSZ 0x0000000000002688 PLTREL 0x0000000000000007 JMPREL 0x0000000000414410 RELA 0x0000000000414398 RELASZ 0x0000000000000078 RELAENT 0x0000000000000018 VERNEED 0x0000000000414258 VERNEEDNUM 0x0000000000000008 VERSYM 0x0000000000413534 Also, obbjdump -p shows additional information like the RPATH , which may be of help when investigating dynamic linking issues with your executable.
+1 for the method that is actually safe and reliable (I’ve somehow got a system where musl-gcc regularly produces binaries such that calling ldd on the binary just executes the binary, so nowadays I am regularly reminded of just how unsafe ldd is).
I did have ldd on my toolcahin, but it unhelpfully just said (lied?) not a dynamic executable , vs. this, which actually made it spill the beans in the DYNAMIC SECTION as you show above.
lsof -P -T -p Application_PID This works better than ldd when the executable uses a non default loader
Used this to find out if mariadb was actually using tc-malloc, which gets loaded by LD_PRELOAD. Works great.
I was looking for something that would show me ‘.so’ for a given pid. This is exactly what I needed. Thanks!
@ychaouche in this old answer I pointed out that lsof is better than ldd, in specific situations, I never mentioned objdump. Am I missing something?
@FabianoTarlao, oh sorry, I’ve added my comment to the wrong answere ! the comment was for this answere stackoverflow.com/a/15520982/212044
to learn what libraries a binary uses, use ldd
You’d have to write a little shell script to get to your system-wide breakdown.
Check shared library dependencies of a program executable
To find out what libraries a particular executable depends on, you can use ldd command. This command invokes dynamic linker to find out library dependencies of an executable.
> $ ldd /path/to/program
Note that it is NOT recommended to run ldd with any untrusted third-party executable because some versions of ldd may directly invoke the executable to identify its library dependencies, which can be security risk.
Instead, a safer way to show library dependencies of an unknown application binary is to use the following command.
$ objdump -p /path/to/program | grep NEEDED
readelf -d recursion
redelf -d produces similar output to objdump -p which was mentioned at: https://stackoverflow.com/a/15520982/895245
But beware that dynamic libraries can depend on other dynamic libraries, to you have to recurse.
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] $ 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 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
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.
On OS X by default there is no ldd , objdump or lsof . As an alternative, try otool -L :
$ otool -L `which openssl` /usr/bin/openssl: /usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8) /usr/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0) In this example, using which openssl fills in the fully qualified path for the given executable and current user environment.
On UNIX system, suppose binary (executable) name is test. Then we use the following command to list the libraries used in the test is
With ldd you can get the libraries that tools use. To rank the usage of libraries for a set of tool you can use something like the following command.
ldd /bin/* /usr/bin/* . | sed -e '/^[^\t]/ d; s/^\t\(.* => \)\?\([^ ]*\) (.*/\2/g' | sort | uniq -c (Here sed strips all lines that do not start with a tab and the filters out only the actual libraries. With sort | uniq -c you get each library with a count indicating the number of times it occurred.)
You might want to add sort -g at the end to get the libraries in order of usage.
Note that you probably get lines two non-library lines with the above command. One of static executables («not a dynamic executable») and one without any library. The latter is the result of linux-gate.so.1 which is not a library in your file system but one «supplied» by the kernel.
One more option can be just read the file located at
For example is the process id is 2601 then the command is
7fb37a8f2000-7fb37a8f4000 r-xp 00000000 08:06 4065647 /usr/lib/x86_64-linux-gnu/libproxy/0.4.15/modules/network_networkmanager.so 7fb37a8f4000-7fb37aaf3000 ---p 00002000 08:06 4065647 /usr/lib/x86_64-linux-gnu/libproxy/0.4.15/modules/network_networkmanager.so 7fb37aaf3000-7fb37aaf4000 r--p 00001000 08:06 4065647 /usr/lib/x86_64-linux-gnu/libproxy/0.4.15/modules/network_networkmanager.so 7fb37aaf4000-7fb37aaf5000 rw-p 00002000 08:06 4065647 /usr/lib/x86_64-linux-gnu/libproxy/0.4.15/modules/network_networkmanager.so 7fb37aaf5000-7fb37aafe000 r-xp 00000000 08:06 4065646 /usr/lib/x86_64-linux-gnu/libproxy/0.4.15/modules/config_gnome3.so 7fb37aafe000-7fb37acfd000 ---p 00009000 08:06 4065646 /usr/lib/x86_64-linux-gnu/libproxy/0.4.15/modules/config_gnome3.so 7fb37acfd000-7fb37acfe000 r--p 00008000 08:06 4065646 /usr/lib/x86_64-linux-gnu/libproxy/0.4.15/modules/config_gnome3.so 7fb37acfe000-7fb37acff000 rw-p 00009000 08:06 4065646 /usr/lib/x86_64-linux-gnu/libproxy/0.4.15/modules/config_gnome3.so 7fb37acff000-7fb37ad1d000 r-xp 00000000 08:06 3416761 /usr/lib/x86_64-linux-gnu/libproxy.so.1.0.0 7fb37ad1d000-7fb37af1d000 ---p 0001e000 08:06 3416761 /usr/lib/x86_64-linux-gnu/libproxy.so.1.0.0 7fb37af1d000-7fb37af1e000 r--p 0001e000 08:06 3416761 /usr/lib/x86_64-linux-gnu/libproxy.so.1.0.0 7fb37af1e000-7fb37af1f000 rw-p 0001f000 08:06 3416761 /usr/lib/x86_64-linux-gnu/libproxy.so.1.0.0 7fb37af1f000-7fb37af21000 r-xp 00000000 08:06 4065186 /usr/lib/x86_64-linux-gnu/gio/modules/libgiolibproxy.so 7fb37af21000-7fb37b121000 ---p 00002000 08:06 4065186 /usr/lib/x86_64-linux-gnu/gio/modules/libgiolibproxy.so 7fb37b121000-7fb37b122000 r--p 00002000 08:06 4065186 /usr/lib/x86_64-linux-gnu/gio/modules/libgiolibproxy.so 7fb37b122000-7fb37b123000 rw-p 00003000 08:06 4065186 /usr/lib/x86_64-linux-gnu/gio/modules/libgiolibproxy.so 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.