102.3. Manage shared libraries
Last updated
Last updated
Weight: 1
Description: 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
Terms and Utilities:
ldd
ldconfig
/etc/ld.so.conf
LD_LIBRARY_PATH
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.
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.
Static libraries vs Shared libraries
Each program using routines from a static library has a copy of them in the executable file. This wastes disk space and (if more than one such program is in use at the same time) RAM as well. Also, when a static library is updated, all the programs using it must be recompiled in order to take advantage of the new code.
When a program uses a shared library instead, the program binary does not include a copy of the code, but only a reference to the library. The run time loader, finds the library and loads it into memory at the same time as the program. One advantage of using dynamic library is that when a library is updated ( security issues ) all other programs take advantage of new code without recompiling.
Dynamic or shared libraries can further be categorized into two groups ( beyond the scope of LPIC exam):
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.
Depending on library, Linux stores its libraries mainly in three locations:
/lib
/usr/lib
/usr/local/lib
/lib : The /lib directory contains those shared library images needed to boot the system and run the commands in the root filesystem, ie. by binaries in /bin and /sbin.
The /lib folder sister folders are /lib32 and /lib64.
/usr/lib : All software libraries are installed here. This does not contain system default or kernel libraries.
/usr/local/lib: To place extra system library files here. These library files can be used by different applications.
Also /var/lib Directory, holds dynamic data libraries/files like the rpm/dpkg database and game scores.
In this article we will discuss specifically about Shared Libraries.
Shared libraries are named in three ways:
library name (a.k.a "soname")
filename (a.k.a "real name")(absolute path to file which stores library code)
"linker name"
1)Every shared library has a special name called the "soname''. The soname has the prefix "lib'', the name of the library, the phrase ".so'', followed by a period and a version number that is incremented whenever the interface changes .
A fully-qualified soname includes as a prefix the directory it's in.
On a working system a fully-qualified soname is simply a symbolic link to the shared library's "real name''.
2)Every shared library also has a "real name'', which is the filename containing the actual library code. The real name adds to the soname a period, a minor number, another period, and the release number. The last period and release number are optional.
3)In addition, there's the name that the compiler uses when requesting a library, (I'll call it the "linker name''), which is simply the soname without any version number.
Okey lets explain all in an example:
Thus, /usr/lib/libreadline.so.6 is a fully-qualified soname, which is set to be a symbolic link to some realname like /usr/lib/libreadline.so.6.3. There should also be a linker name, /usr/lib/libreadline.so which could be a symbolic link referring to /usr/lib/libreadline.so.6.
To get a list of all shared library dependencies for a binary file, you can use the ldd utility. For example lets see what shared libraries are required by ls command:
Try ltrace ls to get surprised! But how poor ls can find its required shared libraries?
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. But How it can find them? Lets show the structure in a picture:
These three files helps programs to find their required shared libraries.
ld.so.conf file tells the system where to look for library files, that is kind of an address book.
Traditionally in the past, it included all the paths which libraries existed. Today more abstraction has been implemented and it just points to ld.so.conf.d directory. Simply it says go to the ld.so.conf.d directory and load any configuration files.
ld.so.conf.d directory contains several configuration files for the kernel or for other third party applications.
Lets see what is inside configuration files :
We can add a new configuration file or edit any of them in order to include a new path.
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 a binary file, so that is not something we usually like to see :
use string command intead and it just shows human readable binary files, also lconfig -p prints cache.
This is very important especially when we have just installed new shared libraries or created our own, or created new library directories. We need to run ldconfig command to effect the changes.(The out put has been truncated):
ldconfig command has some options:
After creating our shared library, we need to install it.
There are several ways to install a dynamic library:
1)We can either move it into any of the standard directories mentioned above, and run the ldconfig command.
2)The method above sets the library path permanently. To set it temporarily, use the LD_LIBRARY_PATH environment variable on the command line.
In Linux, the environment variable LD_LIBRARY_PATH is a colon-separated set of directories where libraries should be searched for first, before the standard set of directories; this is useful when debugging a new library or using a nonstandard library for special purposes.
The usual dynamic linker on Linux uses a cache to find its libraries, So there is no default value for LD_LIBRARY_PATH, default library lookup doesn’t need it at all. If LD_LIBRARY_PATH is defined, then it is used first, but doesn’t disable the other lookups (which also include a few default directories).
Whether it has a default value or not we can use blow command to add our new library path:
Do not forget that these changes are not permanent and If you want to keep the changes permanent, then add above line in the shell initialization file/etc/profile(global) or~/.profile(user specific), which will be discussed in next lessons.
That's all!
.
.
.
Sources:
https://www.tecmint.com/understanding-shared-libraries-in-linux/
https://www.ibm.com/developerworks/linux/library/l-dynamic-libraries/
http://www.linuxforums.org/forum/newbie/151875-what-libraries.html
https://www.linuxnix.com/linux-directory-structure-lib-explained/
https://askubuntu.com/questions/17545/where-does-ubuntu-store-its-library-files
https://medium.com/@jhuang1012bn/static-library-and-shared-library-de6def6b1d3b
http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
https://unix.stackexchange.com/questions/354295/what-is-the-default-value-of-ld-library-path
