Linux find libraries used

Understanding Shared Libraries in Linux

In programming, a library is an assortment of pre-compiled pieces of code that can be reused in a program. Libraries simplify life for programmers, in that they provide reusable functions, routines, classes, data structures and so on (written by a another programmer), which they can use in their programs.

For instance, if you are building an application that needs to perform math operations, you don’t have to create a new math function for that, you can simply use existing functions in libraries for that programming language.

Examples of libraries in Linux include libc (the standard C library) or glibc (GNU version of the standard C library), libcurl (multiprotocol file transfer library), libcrypt (library used for encryption, hashing, and encoding in C) and many more.

Linux supports two classes of libraries, namely:

• Static libraries – are bound to a program statically at compile time.
• Dynamic or shared libraries – are loaded when a program is launched and loaded into memory and binding occurs at run time.

Dynamic or shared libraries can further be categorized into:

• Dynamically linked libraries – here a program is linked with the shared library and the kernel loads the library (in case it’s not in memory) upon execution.
• Dynamically loaded libraries – the program takes full control by calling functions with the library.

Shared Library Naming Conventions

Shared libraries are named in two ways: the library name (a.k.a soname) and a “filename” (absolute path to file which stores library code).

For example, the soname for libc is libc.so.6: where lib is the prefix, c is a descriptive name, so means shared object, and 6 is the version. And its filename is: /lib64/libc.so.6. Note that the soname is actually a symbolic link to the filename.

Locating Shared Libraries in Linux

Shared libraries are loaded by ld.so (or ld.so.x) and ld-linux.so (or ld-linux.so.x) programs, where x is the version. In Linux, /lib/ld-linux.so.x searches and loads all shared libraries used by a program.

A program can call a library using its library name or filename, and a library path stores directories where libraries can be found in the filesystem. By default, libraries are located in /usr/local/lib, /usr/local/lib64, /usr/lib and /usr/lib64; system startup libraries are in /lib and /lib64. Programmers can, however, install libraries in custom locations.

The library path can be defined in /etc/ld.so.conf file which you can edit with a command line editor.

The line(s) in this file instruct the kernel to load file in /etc/ld.so.conf.d. This way, package maintainers or programmers can add their custom library directories to the search list.

If you look into the /etc/ld.so.conf.d directory, you’ll see .conf files for some common packages (kernel, mysql and postgresql in this case):

If you take a look at the mariadb-x86_64.conf, you will see an absolute path to package’s libraries.

The method above sets the library path permanently. To set it temporarily, use the LD_LIBRARY_PATH environment variable on the command line. If you want to keep the changes permanent, then add this line in the shell initialization file /etc/profile (global) or

/.profile (user specific).

Managing Shared Libraries in Linux

Let us now look at how to deal with shared libraries. To get a list of all shared library dependencies for a binary file, you can use the ldd utility. The output of ldd is in the form:

This command shows all shared library dependencies for the ls command.

Sample Output

Because shared libraries can exist in many different directories, searching through all of these directories when a program is launched would be greatly inefficient: which is one of the likely disadvantages of dynamic libraries. Therefore a mechanism of caching employed, performed by a the program ldconfig.

By default, ldconfig reads the content of /etc/ld.so.conf, creates the appropriate symbolic links in the dynamic link directories, and then writes a cache to /etc/ld.so.cache which is then easily used by other programs.

This is very important especially when you have just installed new shared libraries or created your own, or created new library directories. You need to run ldconfig command to effect the changes.

After creating your shared library, you need to install it. You can either move it into any of the standard directories mentioned above, and run the ldconfig command.

Alternatively, run the following command to create symbolic links from the soname to the filename:

To get started with creating your own libraries, check out this guide from The Linux Documentation Project(TLDP).

Thats all for now! In this article, we gave you an introduction to libraries, explained shared libraries and how to manage them in Linux. If you have any queries or additional ideas to share, use the comment form below.

If You Appreciate What We Do Here On TecMint, You Should Consider:

TecMint is the fastest growing and most trusted community site for any kind of Linux Articles, Guides and Books on the web. Millions of people visit TecMint! to search or browse the thousands of published articles available FREELY to all.

If you like what you are reading, please consider buying us a coffee ( or 2 ) as a token of appreciation.

We are thankful for your never ending support.

Источник

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?

8 Answers 8

You can do this with ldd command:

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.

Note that libraries can depend on other libraries, so now you need to find the dependencies.

A naive approach that often works is:

but the more precise method is to understand the ldd search path / cache. I think ldconfig is the way to go.

Choose one, and repeat:

/maps for running processes

Mentioned by Basile, this is useful to find all the libraries currently being used by running executables. E.g.:

shows all currently loaded dynamic dependencies of init (PID 1 ):

This method also shows libraries opened with dlopen , tested with this minimal setup hacked up with a sleep(1000) on Ubuntu 18.04.

Источник

How to see the currently loaded shared objects in Linux?

I have two, related questions:

• How can I see if a shared library is currently loaded? (i.e. system-wide, process agnostic)
• How can I see all shared libraries loaded by a process?

4 Answers 4

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:

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.

is a nice way to explore all /proc/PID/maps mentioned by Rich at once. Sample output:

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.

You can run the next command by root and see a full list,

This is for users who don’t have lsof.

Not the answer you’re looking for? Browse other questions tagged linux libraries or ask your own question.

Linked

Related

Hot Network Questions

Subscribe to RSS

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

site design / logo © 2021 Stack Exchange Inc; user contributions licensed under cc by-sa. rev 2021.10.8.40416

By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.

Источник

Viewing Linux Library / Executable version info

In Windows, EXE and DLL have version info, including at least the following fields:

1. file version
2. product version
3. internal name
4. product name
5. copyright

In Linux Library / Executable:

• Which fields are present?
• How to view such info?
• What tools/libraries to read?

4 Answers 4

The version info in not explicitly stored in an ELF file. What you have in there is the name of the library, the soname , which includes the major version. The full version is usually stored as a part of the library file name.

If you have library, say libtest.so , then you usually have:

• libtest.so.1.0.1 — The library file itself, containing the full version
• libtest.so.1 — Symlink to libtest.so.1.0.1 , having the same name as soname
• libtest.so — Symlink to libtest.so.1 used for linking.

In the library file libtest.so.1.0.1 , there will be an entry called SONAME in dynamic section, that will say this library is called libtest.so.1 . When you link a program against this library, the linked program will store the soname of the library under NEEDED entry in the dynamic section.

If you want to verify, what exactly is in which ELF file, you can try to run:

where elffile can be either an library of an executable.

If you simply want to get the library version, you can play with:

AFAIK, there’s no such info (at least not by default) in executable files.

Or you can rely on the program itself or your packaging system, as Rahul Patil wrote.

Источник

Where do executables look for shared objects at runtime?

I understand how to define include shared objects at linking/compile time. However, I still wonder how do executables look for the shared object ( *.so libraries) at execution time.

For instance, my app a.out calls functions defined in the lib.so library. After compiling, I move lib.so to a new directory in my $HOME .

How can I tell a.out to go look for it there?

4 Answers 4

The shared library HOWTO explains most of the mechanisms involved, and the dynamic loader manual goes into more detail. Each unix variant has its own way, but most use the same executable format (ELF) and have similar dynamic linkers¹ (derived from Solaris). Below I’ll summarize the common behavior with a focus on Linux; check your system’s manuals for the complete story.

(Terminology note: the part of the system that loads shared libraries is often called “dynamic linker”, but sometimes “dynamic loader” to be more precise. “Dynamic linker” can also mean the tool that generates instructions for the dynamic loader when compiling a program, or the combination of the compile-time tool and the run-time loader. In this answer, “linker” refers to the run-time part.)

In a nutshell, when it’s looking for a dynamic library ( .so file) the linker tries:

• directories listed in the LD_LIBRARY_PATH environment variable ( DYLD_LIBRARY_PATH on OSX);
• directories listed in the executable’s rpath;
• directories on the system search path, which (on Linux at least) consists of the entries in /etc/ld.so.conf plus /lib and /usr/lib .

The rpath is stored in the executable (it’s the DT_RPATH or DT_RUNPATH dynamic attribute). It can contain absolute paths or paths starting with $ORIGIN to indicate a path relative to the location of the executable (e.g. if the executable is in /opt/myapp/bin and its rpath is $ORIGIN/../lib:$ORIGIN/../plugins then the dynamic linker will look in /opt/myapp/lib and /opt/myapp/plugins ). The rpath is normally determined when the executable is compiled, with the -rpath option to ld , but you can change it afterwards with chrpath .

In the scenario you describe, if you’re the developer or packager of the application and intend for it to be installed in a …/bin , …/lib structure, then link with -rpath=’$ORIGIN/../lib’ . If you’re installing a pre-built binary on your system, either put the library in a directory on the search path ( /usr/local/lib if you’re the system administrator, otherwise a directory that you add to $LD_LIBRARY_PATH ), or try chrpath .

Источник