Shared Libraries on Linux [Basic Guide]

How Linux Shared Libraries work on Linux, and how this can interfere with the operation of programs.

Determine which libraries are shared for
that an executable program depends on running and installing them when
necessary is part of the objectives of the exam.

To understand library management
shared, we must first understand what libraries are and why
they work.

When writing the source code of a program, the developer makes use of various functions and procedures already defined by the operating system in files called libraries.

These functions allow the programmer to use resources such as writing on disk, writing on the screen, receiving data from the keyboard and mouse, sending data over the network, and much more, without the need to rewrite the wheel.

When the program is compiled, the last stage of its construction is to make the connections.

Some compilers already do this process of gathering all the necessary objects and composing a final object automatically.

Others require the programmer to run another program called a linker. Libraries can be roughly understood as Windows “DLLs”.

/lib64 directory

In modern 64-bit distributions, libraries are located in the /lib64 directory. Depending on the processor architecture, the directory name may vary (e.g. /lib for 32-bit).

Library Types

There are two types of libraries in Linux. As
static and dynamic. The decision of which library to use is the responsibility of
programmer.

When using a static library, the linker finds the functions and procedures that the program needs and physically copies them into the generated executable output file.

This allows the final executable to run independently without using any library. But it is lost in performance, in unnecessary memory consumption, and in the size of the final program.

It is common for programmers to make use of shared libraries instead of static ones. When linking to a program that uses them, the linker makes a reference to shared libraries.

Thus, when this program is executed, the system must first load the necessary libraries, if they are no longer in memory.

In this way, the executables generated are more efficient, since they tend to be smaller, use less memory and occupy less disk space.

The weak point of this methodology is that programs require shared libraries and a change in the versions of these files may also affect their functioning.

What are “soname”?

Every shared library has a special name
called “soname”. Soname consists of the prefix “lib”, followed by the name of
library, the suffix “.so.” and the version number of the library that is increased when the library undergoes changes in its interface.

For example:

libjack-0.80.0.so.0 libvorbis.so.0 libwand.so.6 libjpeg.so.62 libwv2.so.1

Executable files are examined at runtime by the runtime linker called ld.so.

This special interpreter completes the links between the executable and the shared libraries. If ld.so is unable to find and read the dependencies, it will fail and the executable will not load.

Linker connects libraries to software

The ld.so linker maintains an index of all libraries and their location in a special file called /etc/ld.so.cache. It is binary and can therefore be quickly read by ld.so.

That’s why a Linux administrator must be prepared to manage shared libraries and their versions for the correct functioning of the system and its applications.

In this article you can learn more about the process of compiling and “linking” programs in libraries.

Let’s look at the utilities that will help with this
task:

LDD program on Linux

The ldd command — List Dynamic Dependencies —
provides a list of the dynamic dependencies that a given program
precise. It will return the name of the shared library and its location
expected.

Example:

# ldd /bin/bash

libreadline.so.4 => /lib/libreadline.so.4 (0x4001c000)

libhistory.so.4 => /libhistory.so.4 (0x40049000)

libncurses.so.5 => /lib/libncurses.so.5 (0x40050000)

libdl.so.2 => /lib/libdl.so.2 (0x40096000)

libc.so.6 => /lib/ libc.so.6 (0x40099000)

/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

# ldd ldd teste_dijkstra

libc.so.6 => /lib/libc.so.6 (0x4001c000)

/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

This command is important to determine which
are the required libraries of an executable.

Program ldconfig on Linux

The ldconfig utility creates the links and reindexes the dynamic libraries from the /etc/ld.so.cache file.

It searches for libraries in the /usr/lib and /lib directories, as well as in the directories listed in /etc/ld.so.conf, as well as the directory entered on the command line.

The most common options are:

• -p: Lists the contents of the /etc/ld.so.cache cache.
• -v: Shows the progress of updating the cache.
• -f: file informs another configuration file other than the default /etc/ld.so.conf.

Examples:

# ldconfig —p

229 libs found in cache ‘/etc/ld.so.cache’

src_vipa.so (ELF) => /usr/lib/src_vipa.so

libz.so.1 (libc6) => /lib/libz.so.1

(libc6) => /usr/lib/libz.so.1

# ldconfig —v

/usr/X11R6/lib:

libsm.so.6 -> libsm.so.6.0

libdps.so.1 -> libdps.so.1.0

libxrender.so.1 -> libxrender.so.1.2

(…)

LD_LIBRARY_PATH environmental variable

It is still possible to provide it to the linker in time of
Run ld.so a list of extra directories that may contain libraries
shared through the environmental variable LD_LIBRARY_PATH.

A list of directories can be configured, separating them by a colon “:”. This list precedes the list in the ls.so.conf file.

# set | grep LD_LIBRARY_PATH

LD_LIBRARY_PATH=/usr/lib

For security reasons, the LD_LIBRARY_PATH variable
It is ignored by ld.so when it makes connections to programs that have the bit
SUID or SGID enabled.

Its use is common to test new routines in
libraries under development instead of running the routines already installed.

Every time a new library is installed, or a new library version, it is necessary to update the ld.so linker cache with the ldconfig command.

Learn much more about Linux in our online course. You can register here. If you already have an account, or want to create one, just log in or create your user here.

Did you like it?

Share

Uirá Endy Ribeiro

Uirá Endy Ribeiro is a Software Developer and Cloud Computing Architect with a 23-year career. He has master's degrees in computer science and fifteen IT certifications and is the author of 11 books recognized in the IT world market. He is also Director at Universidade Salgado de Oliveira and Director of the Linux Professional Institute - LPI Director's Board.