Shulou(Shulou.com)06/01 Report--

This article introduces the knowledge of "how to use dynamic and static libraries in Linux". Many people will encounter this dilemma in the operation of actual cases, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Understanding how Linux uses libraries, including the differences between static and dynamic libraries, can help you solve dependency problems.

In a sense, Linux is a bunch of interdependent static and dynamic libraries. For newcomers to Linux systems, the whole process of the library is a mystery. But for experienced people, the large amount of shared code built into the operating system is an advantage for writing new applications.

To familiarize you with this topic, I have prepared a small application example to show how libraries are often handled on normal Linux distributions (which are not verified on other operating systems). To use this example to keep up with this hands-on tutorial, open the command line and type:

$git clone https://github.com/hANSIc99/library_sample$ cd library_sample/$ makecc-c main.c-Wall-Werrorcc-c libmy_static_a.c-o libmy_static_a.o-Wall-Werrorcc-c libmy_static_b.c-o libmy_static_b.o-Wall-Werrorar-rsv libmy_static.a libmy_static_a.o libmy_static_b.oar: creating libmy_static.aa-libmy_static_a.oa-libmy_static_b.occ -c-fPIC libmy_shared.c-o libmy_shared.occ-shared-o libmy_shared.so libmy_shared.o$ make cleanrm * .o

When you finish executing these commands, these files should be added to the directory (execute ls to see):

My_applibmy_static.alibmy_shared.so about static links

When your application links to a static library, the code of that library becomes part of the executable file. This action is performed only once during the link process, and these static libraries usually end with the .an extension.

A static library is an archived archive (ar) of multiple target object files. These target files are usually in ELF format. ELF is short for executable chainable format Executable and Linkable Format, which is compatible with multiple operating systems.

The output of the file command tells you that the static library libmy_static.an is an archive file type in ar format.

$file libmy_static.alibmy_static.a: current ar archive

Using ar-t, you can see the inside of the archive file. It shows two target files:

$ar-t libmy_static.alibmy_static_a.olibmy_static_b.o

You can use the ax-x command to extract the files from the archive. All the proposed object files are in ELF format:

$ar-x libmy_static.a$ file libmy_static_a.olibmy_static_a.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped about dynamic links

Dynamic linking refers to the use of shared libraries. Shared libraries usually end with a .so extension (shorthand for "shared object shared object").

Shared library is the most common method of dependency management in Linux system. These shared libraries are loaded into memory before the application starts, and when multiple applications need the same library, the library will only be loaded once in the system. This feature reduces the memory footprint of applications.

It is also worth noting that when the bug of a shared library is fixed, all applications that reference the library will benefit. But it also means that if a bug has not been discovered, all related applications will be affected by the bug (if the application uses the affected part).

When an application requires a specific version of the library, but the linker linker only knows the location of an incompatible version, this is a thorny problem for beginners. In this scenario, you must help the linker find the correct version of the path.

Although this is not a problem you encounter every day, understanding the principles of dynamic links will always help you fix similar problems.

Fortunately, the mechanism for dynamic linking is actually very straightforward.

To check which libraries an application needs when it starts, you can use the ldd command, which prints out the dynamic libraries required for a given file:

$ldd my_app linux-vdso.so.1 (0x00007ffd1299c000) libmy_shared.so = > not found libc.so.6 = > / lib64/libc.so.6 (0x00007f56b869b000) / lib64/ld-linux-x86-64.so.2 (0x00007f56b8881000)

Notice that the libmy_shared.so library is part of the code repository, but is not found. This is because the dynamic linker, which is responsible for loading all dependencies into memory before the application starts, did not find the library under the standard path it searched.

For beginners, issues related to incompatibility with versions of commonly used libraries, such as bizp2, are often confusing. One way is to add the path to the repository to the environment variable LD_LIBRARY_PATH to tell the linker where to find the correct version. In this case, the correct version is in this directory, so you can export it to the environment variable:

$LD_LIBRARY_PATH=$ (pwd): $LD_LIBRARY_PATH$ export LD_LIBRARY_PATH

Now that the dynamic linker knows where to find the library, the application can be executed. You can execute ldd again to call the dynamic linker, which checks the application for dependencies and loads them into memory. The memory address is displayed after the object path:

$ldd my_app linux-vdso.so.1 (0x00007ffd385f7000) libmy_shared.so = > / home/stephan/library_sample/libmy_shared.so (0x00007f3fad401000) libc.so.6 = > / lib64/libc.so.6 (0x00007f3fad21d000) / lib64/ld-linux-x86-64.so.2 (0x00007f3fad408000)

To know which linker has been called, you can use the file command:

$file my_appmy_app: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter / lib64/ld-linux-x86-64.so.2, BuildID [sha1] = 26c677b771122b4c99f0fd9ee001e6c743550fa6, for GNU/Linux 3.2.0, not stripped

The linker / lib64/ld-linux-x86-64.so.2 is a soft link to ld-2.30.so and is the default linker for my Linux distribution:

$file / lib64/ld-linux-x86-64.so.2/lib64/ld-linux-x86-64.so.2: symbolic link to ld-2.31.so

Looking back at the output of the ldd command, you can also see (next to libmy_shared.so) that each dependency ends with a number (for example, / lib64/libc.so.6). Common naming formats for shared objects are:

LibXYZ.so..

In my system, libc.so.6 is also a soft link to a shared object libc-2.31.so in the same directory.

$file / lib64/libc.so.6/lib64/libc.so.6: symbolic link to libc-2.31.so

If you are facing an application that cannot be started due to the wrong version of the loading library, there is a good chance you can solve this problem by checking and sorting out these soft links or determining the correct search path (see the "dynamic Loader: ld.so" section below).

See the ldd man page for more details.

Dynamic loading

Dynamic loading means that a library (such as a .so file) is loaded at run time of the program. This is done using a specific programming method.

Dynamic loading is used when an application uses a plug-in that can be changed at run time.

Check the dlopen man pages for more information.

Dynamic loader: ld.so

In Linux systems, you are almost always dealing with shared libraries, so there must be a mechanism to detect an application's dependency and load it into memory.

Ld.so looks for shared objects in these places in the following order:

Hongmeng official Strategic Cooperation to build HarmonyOS Technology Community

Applied absolute path or relative path (hard-coded with the-rpath option of the GCC compiler)

Environment variable LD_LIBRARY_PATH

/ etc/ld.so.cache file

It is important to remember that administrator privileges are required to add a library to the system library archive / usr/lib64. You can manually copy the libmy_shared.so to the library archive so that the application can run without setting LD_LIBRARY_PATH.

Unset LD_LIBRARY_PATHsudo cp libmy_shared.so / usr/lib64/

When you run ldd, you can now see that the path to the archive library is shown:

$ldd my_app linux-vdso.so.1 (0x00007ffe82fab000) libmy_shared.so = > / lib64/libmy_shared.so (0x00007f0a963e0000) libc.so.6 = > / lib64/libc.so.6 (0x00007f0a96216000) / lib64/ld-linux-x86-64.so.2 (0x00007f0a96401000) customize the shared library at compile time

If you want your application to use your shared library, you can specify an absolute or relative path at compile time.

Edit the makefile (line 10) and then recompile the program through make-B. Then the ldd output shows that libmy_shared.so is listed along with its absolute path.

Put this:

CFLAGS-Wall-Werror-Wl,-rpath,$ (shell pwd)

Change it to this (remember to change the user name):

CFLAGS = / home/stephan/library_sample/libmy_shared.so

Then recompile:

$make

Make sure it is using the absolute path you set, which you can see on the second line of the output:

$ldd my_app linux-vdso.so.1 (0x00007ffe143ed000) libmy_shared.so = > / lib64/libmy_shared.so (0x00007fe50926d000) / home/stephan/library_sample/libmy_shared.so (0x00007fe509268000) libc.so.6 = > / lib64/libc.so.6 (0x00007fe50909e000) / lib64/ld-linux-x86-64.so.2 (0x00007fe50928e000)

This is a good example, but if you are writing a library for others to use, how does it work? The path to the new library can be registered with the system by writing to / etc/ld.so.conf or by creating a .conf file that contains the path in the / etc/ld.so.conf.d/ directory. After that, you must execute the ldconfig command to overwrite the ld.so.cache file. This step is sometimes not omitted when you install a program that carries a special shared library.

Check the man page of ld.so for more details.

How to deal with multiple architectures

Generally speaking, 32-bit and 64-bit versions of applications have different libraries. The following list shows the standard paths for different Linux distribution libraries:

Red Hat Family

32-bit: / usr/lib

64-bit: / usr/lib64

Debian family

32-bit: / usr/lib/i386-linux-gnu

64-bit: / usr/lib/x86_64-linux-gnu

Arch Linux family

32-bit: / usr/lib32

64-bit: / usr/lib64

FreeBSD (not technically Linux distribution)

32-bit: / usr/lib32

64-bit: / usr/lib

Knowing where to find these key libraries can make the problem of library link failure a thing of the past.

Although it may be a little confusing at first, understanding the dependency management of Linux libraries is a sign of a sense of control over the operating system. Run these steps in other applications to familiarize yourself with common libraries, and then continue to learn how to solve any library challenges you may encounter.

That's all for "how to use dynamic and static libraries in Linux". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.