C/C++ program compilation and linking (5) Locating library files

Article directory

- Locate libraries during build

Locating library files includes two aspects:

When the program is built, you need to know the location and header files of the dependent libraries.
When the program is running, you need to know the location of the dependent library, only for the dynamic library.

Only the dynamic library is loaded when the program is running, and the static library is linked into the program when it is built.

Locate libraries during build

Naming rules for static libraries

lib + library name +.a

library nameis the actual name of the static library, for example libtest.a, the library name test.

Naming rules for dynamic libraries

lib + library name + .so + library version information

Compared with the static library, the dynamic library has more version information of the library. After specifying the version information, the library name is the same and the version is different, because the symbols contained are different. We often encounter dynamics that depend on multiple different versions, and the version number is an important way to distinguish these libraries.
So is the actual name of the library library name.
Regardless of whether it is a dependent static library or a dynamic library during construction, the path of the specified library is consistent, and the path of the library file during the construction process is specified through the -Land option. It is the directory of the specified library, the specified library name is the actual name of the library, and the corresponding library is-l
gcc main.o -L../lib -ltestlib -o test
-L-l-ltestliblibtestlib.so或libtestlib.a

-LTells the compiler which directory to use to locate the library.
-lFor a dynamic library, the specified library name will also be written into the final generated execution file. When the program is running, the loader will search for the specified library, but the rules for locating the library are not the same -L.

-lIt can also be followed by path + library name, for example:
gcc main.o -l/home/test/lib/libtestlib.so -o test
But in this way, all the content behind will be written into the execution file. When the program is running, the loader will load the dynamic library -laccording to the fixed location . /home/test/lib/libtestlib.soIf the compiler machine is not the same as the running machine, it will fail because the library cannot be found.

Location rules for runtime dynamic libraries

According to the following rules of priority:

LD_LIBRARY_PATH
ld.so.cache
Default library path (/lib/ and /usr/lib etc.)

rpathThe location of the dynamic library, and the sum of higher priority runpath, these two values will be written into the dynamic library or the execution program ELF file. However, the decision-making process of these two configurations is more complicated, and it also faces the problem of different processing methods for different gcc versions. So they are not listed here. Usually we use LD_LIBRARY_PATHand ldconfigare sufficient.

`LD_LIBRARY_PATH`

Setting environment variables LD_LIBRARY_PATHis a way we often use in the development process, but this is not a standard way, usually to temporarily verify the correctness of the program, you can configure the environment variable, as follows:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:动态库目录

ld.so.cache

ld.so.cacheis the loader's ( ld.soor ld-linux.so) cache file for locating the library directory. It can be updated by ldconfigtools.
A standard code deployment process is ldconfigtool-based, which is usually the last step in the package installation process, and usually requires passing the path to the directory containing the library as an input parameter, writing it to a file, and ensuring that the loader can locate ld.so.cacheall Dependent libraries.

ldconfig creates the necessary links and cache to the most recent shared libraries found in the directories specified on the command line, in the file /etc/ld.so.conf, and in the trusted directories (/lib and /usr/lib).

ldconfigIt will search the specified directory, /etc/ld.so.conf, the system library default directory /lib, /usr/lib. Write the path information of the library in it /etc/ld.so.cach, which is used by the linker ( ld.soor ld-linux.so) to find the dependent library.

ldconfigAnother important function is to update the version of the dynamic library, which will be described in detail in the following documents.

So when we need to locate our own dependent libraries, we can write the directory directly /etc/ld.so.conf, but /etc/ld.so.confusually it is as follows:

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

**include ld.so.conf.d/*.conf**Indicates that all files in the directory are included **/etc/ld.so.conf.d/**, so we usually create a conf file in this directory that contains the dependent library directory.

#ls -lrt /etc/ld.so.conf.d/
-rw-r--r-- 1 root root 19 8月   9 2019 dyninst-x86_64.conf
-rw-r--r-- 1 root root 17 4月   3 2020 mariadb-x86_64.conf
-rw-r--r-- 1 root root 26 6月   1 2020 bind-export-x86_64.conf
-r--r--r-- 1 root root 63 8月  26 2020 kernel-3.10.0-1127.19.1.el7.x86_64.conf
#ldconfig

Then by ldconfigletting it update the directory to /etc/ld.so.cachthe file, you can ldconfig -pcheck whether the dynamic library and its path information cached in the cache have been written ( ldconfig -p | grep 依赖的动态库).