How to find out where a program is looking for libraries
The other day I came across a linux command that let me see where a program is expecting to find its libraries. It is very useful to solve library dependency problems for not so popular or proprietary software. I used ldd , it was very informative, but missed one crucial piece of information for me: ldd -v ./my_executable gave good information for libraries that my_executable can link to. But for those it can not link/find, ldd only gave information like:
3 Answers 3
on linux you can use the LD_DEBUG. This link is helpful.
Probably you need the strace command Take a look here http://www.thegeekstuff.com/2011/11/strace-examples/
strace -e open ./my_executable shows pretty much what I want to see. I had the impression that the command I was looking for gives more concise output though. I accept this as the answer anyway.
The information about library paths is stored in /etc/ld.so.conf :
/usr/local/lib64 /usr/local/lib include /etc/ld.so.conf.d/*.conf # /lib64, /lib, /usr/lib64 and /usr/lib gets added # automatically by ldconfig after parsing this file. # So, they do not need to be listed. See man ldconfig for more information.
I am aware of this. However, some programs will look for library from /path/to/installation/dir/libraries . What worse, this path can be hard-coded, and it is different from the actual installation path.
But why should ldd list all directories where it is looking? You can get this info from /etc/ld.so.conf and you can also look if LD_LIBRARY_PATH is set. See this documentation.
How do you find libraries (C++) in Ubuntu?
Solution 1: By default libraries are installed in and header files will be in Usually extension of the library file is .so and corresponding header file will be .h gui method for finding installed libraries is open software center->Developer tools-> Libraries Solution 2: The brute strength approach is: Updatedb takes a few moments; please be patient. It does NOT take into account libraries in LD_LIBRARY_PATH (contrarily to what this post said before edit) but you can pass additional libraries to the command line by using the line below: Solution 2: You can compile a simple test program with gcc and link your library.
How do you find libraries (C++) in Ubuntu?
By default libraries are installed in /usr/lib and header files will be in /usr/include
Usually extension of the library file is .so and corresponding header file will be .h
gui method for finding installed libraries is open software center->Developer tools-> Libraries
The brute strength approach is:
sudo updatedb locate libpcl Updatedb takes a few moments; please be patient. The library you’re looking for is likely in /usr/lib.
Find out if library is in path, ldconfig can list all the libraries it has access to. These libraries are also stored in its cache. /sbin/ldconfig -v -N will crawl all the usual library paths, list all the available libraries, without reconstructing the cache (which is not possible if you’re a non-root user).
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) 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] - Determine direct shared object dependencies of a Linux binary? | Stack Overflow
- How can I find the dynamic libraries required by an ELF Binary in C++? | Stack Overflow
- How to know which dynamic libraries are needed by an ELF? | Stack Overflow
/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.
See also: How to see the currently loaded shared objects in Linux? | Super User
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.
How can I see my installed libraries in python ?, Find centralized, trusted content and collaborate around the technologies you use most. Learn more about Collectives Teams. Q&A for work I would like to have a list with my installed libraries in my python console. How can be that possible ? python libraries. Share.
Find out if library is in path
ldconfig can list all the libraries it has access to. These libraries are also stored in its cache.
/sbin/ldconfig -v -N will crawl all the usual library paths, list all the available libraries, without reconstructing the cache (which is not possible if you’re a non-root user). It does NOT take into account libraries in LD_LIBRARY_PATH (contrarily to what this post said before edit) but you can pass additional libraries to the command line by using the line below:
You can compile a simple test program with gcc and link your library. Then you can check the used libraries with ldd. I use something like this:
echo "int main()<>" | gcc -x c++ -Wl,--no-as-needed -lmylib - && ldd a.out | grep mylib -Wl,—no-as-needed prevents the linker from discarding the library, because no symbols from the library are used.
Globally substitute (space) for : with LD_LIBRARY_PATH
How to list all Linux environment variables including, If LD_LIBRARY_PATH is not there, then that variable was not declared; or was declared but not exported, so that child processes do not inherit it. If you are setting LD_LIBRARY_PATH in your shell start-up files, like .bash_profile or .bashrc make sure it is exported: export LD_LIBRARY_PATH
How to find location of installed library
Background: I’m trying to build my program but first I need to set up libraries in NetBeans. My project is using GLU and therefore I installed libglu-dev. I didn’t note the location where the libraries were located and now I can’t find them. I’ve switched to Linux just a few days ago and so far I’m very content with it, however I couldn’t google this one out and became frustrated. Is there way to find out where files of package were installed without running the installation again? I mean if I got library xxx and installed it some time ago, is there some-command xxx that will print this info? I’ve already tried locate, find and whereis commands, but either I’m missing something or I just can’t do it correctly. For libglu, locate returns:
/usr/share/bug/libglu1-mesa /usr/share/bug/libglu1-mesa/control /usr/share/bug/libglu1-mesa/script /usr/share/doc/libglu1-mesa /usr/share/doc/libglu1-mesa/changelog.Debian.gz /usr/share/doc/libglu1-mesa/copyright /usr/share/lintian/overrides/libglu1-mesa /var/lib/dpkg/info/libglu1-mesa:i386.list /var/lib/dpkg/info/libglu1-mesa:i386.md5sums /var/lib/dpkg/info/libglu1-mesa:i386.postinst /var/lib/dpkg/info/libglu1-mesa:i386.postrm /var/lib/dpkg/info/libglu1-mesa:i386.shlibs The other two commands fail to find anything. Now locate did its job, but I’m sure none of those paths is where the library actually resides (at least everything I was linking so far was in /usr/lib or /usr/local/lib ). libglu was introduced just as example. I’m looking for a general solution for this problem.