Which libraries are linked

These search paths are used by the runtime linker to locate any shared object dependencies. These recorded search paths are referred to as a runpath.

Objects may be built with the -z nodefaultlib option to suppress any search of the default locations at runtime. Use of this option implies that all the dependencies of an object can be located using its runpaths.

Default search paths can be administrated using a runtime configuration file. See "Configuring the Default Search Paths". However the creator of an object should not rely on the existence of this file, and should always ensure that their object can locate its dependencies with only its runpaths or standard system defaults. You can use the -R option, which takes a colon-separated list of directories, to record a runpath in a dynamic executable or shared object.

In this case, this runpath is used to locate libfoo. The link-editor accepts multiple -R options and concatenates each of these specifications, separated by a colon. Thus, the previous example can also be expressed as:. See "Locating Associated Dependencies". Linking With Additional Libraries Although the compiler drivers often ensure that appropriate libraries are specified to the link-editor, frequently you must supply your own.

Library Naming Conventions By convention, shared objects are usually designated by the prefix lib and the suffix. Linking With a Mix of Shared Objects and Archives The library search mechanism in dynamic mode searches a given directory for a shared object, and then searches an archive library. Position of an Archive on the Command Line The position of an archive on the command line can affect the output file being produced. Using a Command-Line Option You can use the -L option to add a new path name to the library search path.

Note - You must specify -L if you want the link-editor to search for libraries in your current directory. Note - Default search paths can be administrated using a runtime configuration file. As you can see, errors might occur anywhere along the code, so we should be carefull to make extensive error checking.

The final step is to close down the library, to free the memory it occupies. This should only be done if we are not intending to use it soon. If we do - it is better to leave it open, since library loading takes time. It may be used to invoke some startup code needed to initialize data structures used by the library, read configuration files, and so on. It may be used to make cleanup operations required by the library freeing data structures, closing files, etc. For an example of a program that uses the 'dl' interface, try looking at our dynamic-shared library example directory.

In order to fully understand the way linking is done, and be able to overcome linking problems, we should bare in mind that the order in which we present the object files and the libraries to the linker, is the order in which the linker links them into the resulting binary file.

The linker checks each file in turn. If it is an object file, it is being placed fully into the executable file. If it is a library, the linker checks to see if any symbols referenced i. If such a symbol is found, the whole object file from the library that contains the symbol - is being added to the executable file. This process continues until all object files and libraries on the command line were processed.

This process means that if library 'A' uses symbols in library 'B', then library 'A' has to appear on the link command before library 'B'. Otherwise, symbols might be missing - the linker never turns back to libraries it has already processed.

This also hints that one should try not to have such mutual dependencies between two libraries. If you have such dependencies - then either re-design your libraries' contents, or combine the two libraries into one larger library.

Note that object files found on the command line are always fully included in the executable file, so the order of mentioning them does not really matter. Thus, a good rule is to always mention the libraries after all object files.

When we discussed static libraries we said that the linker will try to look for a file named 'libutil. We lied. Before looking for such a file, it will look for a file named 'libutil. Only if it cannot find a shared library, will it look for 'libutil. Thus, if we have created two copies of the library, one static and one shared, the shared will be preferred.

This can be overridden using some linker flags '-Wl,static' with some linkers, '-Bstatic' with other types of linkers. This document is copyright c by guy keren. The material in this document is provided AS IS, without any expressed or implied warranty, or claim of fitness for a particular purpose. Neither the author nor any contributers shell be liable for any damages incured directly or indirectly by using the material contained in this document.

I think you may need to use ldd -v — MountainX. 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.

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 — Tim Bird.

This should be safe too, unlike ldd which shouldn't be used on untrusted executables. Also, obbjdump -p shows additional information like the RPATH , which may be of help when investigating dynamic linking issues with your executable.

Community Bot 1 1 1 silver badge. Fabiano Tarlao Fabiano Tarlao 2, 31 31 silver badges 36 36 bronze badges. Works great. I was looking for something that would show me '. This is exactly what I needed. Check shared library dependencies of a program executable To find out what libraries a particular executable depends on, you can use ldd command. Then we use the following command to list the libraries used in the test is ldd test. Raghwendra Raghwendra 71 1 1 silver badge 1 1 bronze badge. You might want to add sort -g at the end to get the libraries in order of usage.

SoSen SoSen 7 7 bronze badges. Improve this question. Add a comment. Active Oldest Votes. Improve this answer. Any idea of what would be a macOS equivalent of this? No lld on darwin, it appears, nor can I find it via homebrew. So if the binary is untrusted, it may be better to not use ldd.

See man page. I used this snippet to locate the deps and then copy them to my jail Show 2 more comments. See also: Determine direct shared object dependencies of a Linux binary? Nice part about readelf method is that it works on cross-binaries ex: armhf on amd64 as well — Ghostrider. Thomas Dickey Thomas Dickey Nice method. Marcel Gongora Marcel Gongora 2 2 silver badges 3 3 bronze badges.

For mass query: create a small script useslib and put in in the PATH orspecify a full path in the command below!