102.3 Manage shared libraries

Candidates should be able to determine the shared libraries that executable programs depend on and install them when necessary.

Key Knowledge Areas

Identify shared libraries
Identify the typical locations of system libraries.
Load shared libraries.

Introduction

A library is a set of functions that programs can use to implement their functionalities. When building (linking) a program, those libraries can be statically or dynamically linked to an executable. Static link means that the final program will contain the library function within its file. (lib.a) Dynamic link means that the needed libraries are loaded into RAM when the program executes (lib.so).

When writing an application developers make use of existing software libraries to provide functionality needed by their applications. When the final application is compiled there are two options available.

Build the applications with all required libraries compiled into the application. This is known as statically linking the libraries to the application. This has the advantage that the application will have no dependency problems once installed, but has the negative side effect of increasing the size of the binary because the library is duplicated in every application that statically links the library. The most negative effect though is that the kernel cannot optimise memory by loading the duplicated code only once. Instead the same code is loaded for each application.
Dynamically link the required dependencies at run time. Dynamically linked executables are much smaller than when the same application is statically linked programs as they do not contain the library code on which they depend. The use of dynamic linking allows running programs, which use the same library, to share one copy of that library, rather than occupy memory with duplicate copies. Because the library code is separate, it is possible for the Linux distributions package management system to update the library code independently of the application. For these reasons, most programs today use dynamic linking.

In order to find libraries, required by an application at runtime, Linux needs to know where to find them. By default Linux looks in the following trusted locations for library files:

/lib: - Used mainly by /bin programs.
/usr/lib - Used mainly by /usr/bin programs.

Additional locations for library files can specified in the /etc/ld.so.conf file. The ld.so.conf file may include all files under the /etc/ld.so.conf.d directory, depending on your distribution. Listing 5 shows the contents of /etc/ld.so.conf on a 64-bit Fedora 12 system.

Content of /etc/ld.so.conf

$ cat /etc/ld.so.conf

include ld.so.conf.d/*.conf

$ ls /etc/ld.so.conf.d/*.conf

/etc/ld.so.conf.d/kernel-2.6.31.12-174.2.19.fc12.x86_64.conf

/etc/ld.so.conf.d/kernel-2.6.31.12-174.2.22.fc12.x86_64.conf

/etc/ld.so.conf.d/kernel-2.6.31.12-174.2.3.fc12.x86_64.conf

/etc/ld.so.conf.d/mysql-x86_64.conf

/etc/ld.so.conf.d/qt-x86_64.conf

/etc/ld.so.conf.d/tix-x86_64.conf

/etc/ld.so.conf.d/xulrunner-64.conf

In order to optimise library location and loading, the directories in the ld.so.conf file and the trusted directories are parsed by the ldconfig command to create a fast caches at /etc/ld.so.cache.

When an application is launched the dynamic loader uses the cached information from ld.so.cache to locate files. Any changes to the ld.so.conf files requires the ldconfig command to be run to update the /etc/ld.so.cache file.

The ldd command

If you wish to know whether an application is statically linked, or what the dependencies for a dynamically linked application are you can use the ldd command. For example ldd /usr/sbin/apache show the following:

ldd /usr/sbin/apache2

linux-vdso.so.1 => (0x00007ffff85ff000)

libpcre.so.3 => /lib/libpcre.so.3 (0x00007feeaf2e4000)

libaprutil-1.so.0 => /usr/lib/libaprutil-1.so.0 (0x00007feeaf0c1000)

libapr-1.so.0 => /usr/lib/libapr-1.so.0 (0x00007feeaee8b000)

libpthread.so.0 => /lib/libpthread.so.0 (0x00007feeaec6e000)

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

libuuid.so.1 => /lib/libuuid.so.1 (0x00007feeae6e5000)

librt.so.1 => /lib/librt.so.1 (0x00007feeae4dd000)

libcrypt.so.1 => /lib/libcrypt.so.1 (0x00007feeae2a4000)

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

libexpat.so.1 => /lib/libexpat.so.1 (0x00007feeade76000)

/lib64/ld-linux-x86-64.so.2 (0x00007feeaf7ab000)

This tells us that apache2 is dynamically linked and relies on the libraries listed. If a library is missing ldd will out the dependency with the words “not found”. This can be useful when troubleshooting dependency issues.

The LD_LIBRARY_PATH

Sometime you may need to override the default search path for dynamic libraries. This can be for applications you have installed from source, for testing out latest version of a library or if the application relies on an older version of a library that you already have installed on your machine.

To add libraries to the search path you will need to define and export the LD_LIBRARY_PATH variable as follows:

# export LD_LIBRARY_PATH=/usr/lib/:/opt/someapp/lib;

LD_LIBRARY_PATH is a colon-separated list of directories that is searched before the system ones specified in ld.so.cache. This allows for the temporary overriding of libraries defined in the ld.so.cache and in the trusted directories.

Used files, terms and utilities:

ldd
ldconfig
/etc/ld.so.conf
LD_LIBRARY_PATH

Previous Chapter | Next Chapter