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

This article "Linux static library and dynamic library how to make" most people do not understand, so the editor summarized the following content, detailed, clear steps, with a certain reference value, I hope you can get something after reading this article, let's take a look at this "Linux static library and dynamic library how to make" article it.

A static library is a collection of object files during compilation. The static library is used when the program is linked, and the linker copies the code that uses the function in the program from the library file to the application.

Compared with the static function library, the dynamic function library is not compiled into the object code at compile time, but is just marked. Then when the program starts to run, the required modules are loaded dynamically, so the executable files generated by the dynamic function library are relatively small.

In Linux systems:

1. The static library has the extension .a; 2. The dynamic library has a .so extension

The conversion of source code to an executable program requires the process shown in the following figure:

1. Compilation refers to the process of converting a program written in a high-level language into an assembly language program of the corresponding processor. two。 Assembler is the process of generating binary code (machine code) of the target system from assembly language programs. 3. Linking refers to combining multiple pieces of machine code generated by assembly into an executable program.

Through the compilation and assembly process, each source file will generate an object file. The role of the connector is to combine these target files, including the merging of code segments, data segments and other parts, as well as adding the corresponding file headers.

How does the resulting executable work:

The ELF file format includes three main types: executable files, redirectable files, and shared libraries.

1. Executable file (application)

Executable files contain code and data and are programs that can be run directly.

2. Redirectable files (* .o)

A redirectable file, also known as an object file, contains code and data (which is used when connecting with other relocatable files and shared object files).

The .o file participates in the connection of the program (creating a program) and the execution of the program (running a program). It provides a convenient and effective way to look at the contents of the file from a parallel perspective, and the activities of these .o files can reflect different needs.

Under Linux, we can compile the source file into * .o format when we compile it with gcc-c.

3. Share files (* .so)

Also known as a dynamic library file, it contains code and data (which is used by connector ld and runtime dynamic connectors at connection time). Dynamic connectors may be called ld.so.1,libc.so.1 or ld-linux.so.1. On my CentOS6.0 system, the file is: / lib/ld-2.12.so

A library is a binary format of executable code that can be loaded into memory for execution. Libraries are divided into static libraries and dynamic libraries:

Static library: the name of this type of library is usually the name of libxxx.a,xxx as the library. The file compiled by using the static function library is relatively large, because all the data of the whole function library will be integrated into the object code, its advantage is obvious, that is, the compiled execution program does not need external function library support. because all the functions used have been compiled. Of course, this will also be his disadvantage, because if the static function library changes, then your program must be recompiled.

Dynamic library: the name of this type of library is generally libxxx.M.N.so, the same xxx is the name of the library, M is the major version number of the library, and N is the minor version number of the library. Of course, you don't need a version number, but you must have a name. Compared with the static function library, the dynamic function library is not compiled into the object code at the time of compilation, and your program does not call the corresponding function in the library until the relevant function is executed, so the executable file generated by the dynamic function library is relatively small. Because the function library is not integrated into your program, but is dynamically applied and called while the program is running, the corresponding library must be provided in the running environment of the program. The change of dynamic function library does not affect your program, so the upgrade of dynamic function library is more convenient. The linux system has several important directories for the corresponding function libraries, such as / lib / usr/lib.

When you want to use a static library, the connector finds the functions the program needs and copies them to the execution file. Because this copy is complete, once the connection is successful, the static library is no longer needed. However, this is not the case for dynamic libraries. The dynamic library leaves a mark in the executing program indicating that the library must be loaded first when the program is executed. Because dynamic libraries save space, the default operation to connect under linux is to connect dynamic libraries first, that is, if both static and dynamic libraries exist and are not specifically specified, they will be connected to dynamic libraries.

Make a static link library:

1. Prepare two source files, st1.cpp and st2.cpp, and use them to make the library libmytest.a

Xzj@xzj-VirtualBox:~/development_test/static_lib_test$ cat st1.cpp#include using namespace std;void display1 () {cout "This is my first static librarian managers!" # include using namespace std;void display2 () {cout "This is my second static library"

two。 Generate the target file from two source files

Total amount of xzj@xzj-VirtualBox:~/development_test/static_lib_test$ gags +-c st1.cpp st2.cppxzj@xzj-VirtualBox:~/development_test/static_lib_test$ ll 24drwxrwxr-x 2 xzj xzj 4096 July 16 15:39. / drwxrwxr-x 7 xzj xzj 4096 July 16 15:26.. /-rw-rw-r-- 1 xzj xzj 115 July 16 15:35 st1.cpp-rw-rw-r-- 1 xzj xzj 2680 July 16 15:39 St1.o-rw-rw-r-- 1 xzj xzj 113 July 16 15:35 st2.cpp-rw-rw-r-- 1 xzj xzj 2680 July 16 15:39 st2.o

3. Using ar-rsv libmytest.a st1.o st2.o to make static Library

Xzj@xzj-VirtualBox:~/development_test/static_lib_test$ ar-rsv libmytest.a st1.o st2.oar: creating libmytest.aa-st1.oa-st2.oxzj@xzj-VirtualBox:~/development_test/static_lib_test$ ll total usage 32drwxrwxr-x 2 xzj xzj 4096 July 16 15:42. / drwxrwxr-x 7 xzj xzj 4096 July 16 15:26.. /-rw-rw-r-- 1 xzj xzj 5586 July 16 15:42 libmytest. St1.cpp-rw-rw-r-- 1 xzj xzj 2680 July 16 15:39 st1.o-rw-rw-r-- 1 xzj xzj 113 July 16 15:35 st2.cpp-rw-rw-r-- 1 xzj xzj 2680 July 16 15:39 st2.o use the file command to view its attributes It is found that it is indeed an archive compressed file xzj@xzj-VirtualBox:~/development_test/static_lib_test$ file libmytest.alibmytest.a: current ar archive uses ar-t libmytest.a to see which obj files are contained in a static library: xzj@xzj-VirtualBox:~/development_test/static_lib_test$ ar-t libmytest.ast1.ost2.o

4. Write a test program to call the two interfaces display1 () and display2 () provided in the library libmytest.a.

Xzj@xzj-VirtualBox:~/development_test/static_lib_test$ cat main.cppvoid display1 (); void display2 (); int main () {display1 (); display2 (); return 0 } xzj@xzj-VirtualBox:~/development_test/static_lib_test$ gathers +-o run main.cpp-L.L /-lmytestxzj@xzj-VirtualBox:~/development_test/static_lib_test$ ll Total amount 48drwxrwxr-x 2 xzj xzj 4096 July 16 15:54. / drwxrwxr-x 7 xzj xzj 4096 July 16 15:26.. /-rw-rw-r-- 1 xzj xzj 5586 July 16 15:42 libmytest.a-rw-rw-r-- 1 xzj xzj 95 July 16 15:53 main.cpp-rwxrwxr-x 1 xzj xzj 9424 July 16 15:54 run*-rw-rw-r-- 1 xzj xzj 115 July 16 15:35 st1.cpp-rw-rw-r-- 1 xzj xzj 2680 July 16 15:39 st1.o-rw-rw-r-- 1 xzj xzj 113 July 16 15:35 st2.cpp-rw-rw-r-- 1 xzj xzj 2680 July 16 15:39 st2.o result call Success: xzj@xzj-VirtualBox:~/development_test/static_lib_test$. / runThis is my first static librarian created a dynamic library with this is my second static library

Static library * .a files exist mainly to support older executables in a.out format. At present, the most commonly used is the dynamic library.

The suffix of the dynamic library is * .so. Most of the dynamic libraries in the Linux distribution are basically located in / usr/lib and / lib directories. Before developing and using our own dynamic libraries, please allow me to nag you about things related to dynamic libraries under Linux.

Sometimes when our application doesn't work, it tells us what kind of library it can't find, or which version of the library is not to its taste, and so on. So how does the application know which libraries are needed? We have learned a few great commands, ldd, to see which so library files a file depends on.

The configuration file of the dynamic link library in the Linux system is usually in the / etc/ld.so.conf file, and the content in it is the name of the directory where the dynamic link library can be shared by Linux. In my system, the contents of this file are as follows:

Xzj@xzj-VirtualBox:/etc$ cat / etc/ld.so.confinclude / etc/ld.so.conf.d/*.conf

Then many * .conf files are stored in the / etc/ld.so.conf.d/ directory, as follows:

Xzj@xzj-VirtualBox:/etc$ ls / etc/ld.so.conf.d/fakeroot-x86_64-linux-gnu.conf libc.conf x86_64-linux-gnu_GL.confi386-linux-gnu.conf x86_64-linux-gnu.conf zz_i386-biarch-compat.confi386-linux-gnu_GL.conf x86_64-linux-gnu_EGL.conf zz_x32-biarch-compat.conf of which each The conf files represent the library configuration content of an application Take libc as an example: xzj@xzj-VirtualBox:/etc$ cat / etc/ld.so.conf.d/libc.conf# libc default configuration/usr/local/lib also has a file called ld.so.cache in the / etc directory. From the name, we know that it must be some kind of cache file for the dynamic link library. Xzj@xzj-VirtualBox:/etc$ ls-l | grep ld.so.cache-rw-r--r-- 1 root root 125054 July 16 09:09 ld.so.cache

In order to make dynamic link libraries available to the system, when we modify any files in the / etc/ld.so.conf or / etc/ld.so.conf.d/ directory, or copy new dynamic link library files to those directories, we need to run a very important command: ldconfig, which is located in the / sbin directory, and its main purpose is to search / lib and / usr/lib And search for available dynamic link library files in the directory listed in the configuration file / etc/ld.so.conf, and then create the links and (default) cache files / etc/ld.so.cache needed by the dynamic loader / lib/ld-linux.so.2 at the creation place (this file holds a sorted list of dynamic link library names).

In other words: when a user creates or copies a dynamic link library under a directory, if you want it to be shared by the system, you can execute the command "ldconfig directory name". The function of this command is to let ldconfig share the dynamic link libraries in the specified directory with the system, that is, append the shared libraries in the specified directory in the cache file / etc/ld.so.cache. Please note: if this directory is not in the directory listed in the / lib,/usr/lib and / etc/ld.so.conf files, the dynamic link libraries in this directory may not be shared by the system when you run ldconfig separately again. When you run ldconfig alone, it only searches / lib, / usr/lib, and the directories listed in the / etc/ld.so.conf file, and uses them to rebuild / etc/ld.so.cache.

So, later, the shared library we developed can copy it to the / lib, / etc/lib directory, or modify the / etc/ld.so.conf file to add our own library path to the file, and then execute the ldconfig command.

The actual combat of the dynamic library is carried out.

We have a header file my_so_test.h and three source files test_hubei.cpp, test_wuhan.cpp, and test_xiaogan.cpp, and make them into a dynamic link library file called libtest.so:

Header file: xzj@xzj-VirtualBox:~/development_test/dynamic_lib_test$ cat my_so_test.h#ifndef MY_SO_TEST_H#define MY_SO_TEST_Hvoid test_hubei (); void test_wuhan (); void test_xiaogan (); # endif three source files: xzj@xzj-VirtualBox:~/development_test/dynamic_lib_test$ cat test_hubei.cpp#include "my_so_test.h" # include using namespace std Void test_hubei () {cout "Welcome to Hubei" # include "my_so_test.h" # include using namespace std;void test_wuhan () {cout "Welcome to Wuhan" # include "my_so_test.h" # include using namespace std Void test_wuhan () {cout "Welcome to Wuhan" method of producing .so files: method 1: 1. Mr. target .o file: xzj@xzj-VirtualBox:~/development_test/dynamic_lib_test$ gathers +-c * .cppxzj@xzj-VirtualBox:~/development_test/dynamic_lib_test$ ll total usage 36drwxrwxr-x 2 xzj xzj 4096 July 16 17:21. / drwxrwxr-x 8 xzj xzj 4096 July 16 16:26.. /-rw-rw-r-- 1 xzj xzj 108 July 16 17:14 my_so_test.h-rw-rw-r-- 1 xzj xzj July 16 17:18 test_hubei.cpp-rw-rw-r-- 1 xzj xzj 2664 July 16 17:21 test_hubei.o-rw-rw-r-- 1 xzj xzj 125 July 16 17:19 test_wuhan.cpp-rw-rw-r-- 1 xzj xzj 2664 July 16 17:21 test_wuhan.o-rw-rw-r-- 1 xzj xzj 127 July 16 17:20 test_xiaogan.cpp-rw-rw-r-- 1 xzj xzj 2672 July 16 17:21 test_xiaogan.o2, Generate the so file again: xzj@xzj-VirtualBox:~/development_test/dynamic_lib_test$ gathers +-shared-fPCI-o libcity.so test_hubei.o test_wuhan.o test_xiaogan.og++: error: unrecognized command line option'- fPCI' has an error I used the second method. Method 2: xzj@xzj-VirtualBox:~/development_test/dynamic_lib_test$ gathers + test_hubei.cpp test_wuhan.cpp test_xiaogan.cpp-fPIC-shared-o libtest.soxzj@xzj-VirtualBox:~/development_test/dynamic_lib_test$ ll Total usage 48drwxrwxr-x 2 xzj xzj 4096 July 16 17:37. / drwxrwxr-x 8 xzj xzj 4096 July 16 16:26.. /-rwxrwxr-x 1 xzj xzj 9048 July 16 17:37 libtest.so*- Rw-rw-r-- 1 xzj xzj 108 July 16 17:14 my_so_test.h-rw-rw-r-- 1 xzj xzj 125 July 16 17:18 test_hubei.cpp-rw-rw-r-- 1 xzj xzj 2664 July 16 17:21 test_hubei.o-rw-rw-r-- 1 xzj xzj 125 July 16 17:19 test_wuhan.cpp-rw-rw-r-- 1 xzj xzj 2664 July 16 17:21 test_wuhan. There are two ways to use the test_xiaogan.o dynamic link library: it can be dynamically linked at run time. There are two ways to use the test_xiaogan.cpp-rw-rw-r-- xzj xzj 16 17:20 test_xiaogan.cpp-rw-rw-r-- 1 xzj xzj 2672 July 16 17:21 Can also be dynamically loaded in the program is to use them

+ + the use of dynamic libraries +

Usage one: dynamic link.

Xzj@xzj-VirtualBox:~/development_test/dynamic_lib_test$ gathers + main.cpp-o run-L. -Total amount of ltestxzj@xzj-VirtualBox:~/development_test/dynamic_lib_test$ ll 64drwxrwxr-x 2 xzj xzj 4096 July 16 18:14. / drwxrwxr-x 8 xzj xzj 4096 July 16 16:26.. /-rwxrwxr-x 1 xzj xzj 9048 July 16 17:37 libtest.so*-rw-rw-r-- 1 xzj xzj 130 July 16 17:55 main.cpp-rw-rw-r-- 1 xzj xzj 108 July 16 17:14 my_so_test H-rwxrwxr-x 1 xzj xzj 8688 July 16 18:14 run*-rw-rw-r-- 1 xzj xzj 125 July 16 17:18 test_hubei.cpp-rw-rw-r-- 1 xzj xzj 2664 July 16 17:21 test_hubei.o-rw-rw-r-- 1 xzj xzj 125 July 16 17:19 test_wuhan.cpp-rw-rw-r-- 1 xzj xzj 2664 July 16 17:21 test_wuhan.o-rw-rw- Test_xiaogan.cpp-rw-rw-r-- 1 xzj xzj 2672 July 16 17:21 test_xiaogan.oxzj@xzj-VirtualBox:~/development_test/dynamic_lib_test$ LD_LIBRARY_PATH=. . / run Welcome to Hubei Welcome to Wuhan Welcome to Xiaogan Link main.cpp and libtest.so into an executable main. The command is as follows:

$main.cpp + main.cpp-o run-L. -ltest

Test whether the executable main has been linked to the dynamic library libtest.so, if libtest.so is listed, then the link is normal. You can execute the following command: $ldd runxzj@xzj-VirtualBox:~/development_test/dynamic_lib_test$ ldd runlinux-vdso.so.1 = > (0x00007ffe08fc7000) libtest.so = > not foundlibc.so.6 = > / lib/x86_64-linux-gnu/libc.so.6 (0x00007f685d1a2000) / lib64/ld-linux-x86-64.so.2 (0x00007f685d56c000) the following error occurs if you execute the executable file run directly: xzj@xzj-VirtualBox:~/ Development_test/dynamic_lib_test$. / run./run: error while loading shared libraries: libtest.so: cannot open shared object file: No such file or directory here we pay attention to The output of ldd indicates that our libtest.so dynamic library was not found. Because our libtest.so is neither in / etc/ld.so.cache, nor in any directory specified by / lib, / usr/lib, or / etc/ld.so.conf. Solution: method 1: LD_LIBRARY_PATH=. Executable file xzj@xzj-VirtualBox:~/development_test/dynamic_lib_test$ LD_LIBRARY_PATH=. . / run Welcome to Hubei Welcome to Wuhan Welcome to Xiaogan method 2: if you are developing a software or giving your system DIY a very useful function module, it is recommended that you copy libtest.so to / lib, / usr/lib directory Xzj@xzj-VirtualBox:~/development_test/dynamic_lib_test$ sudo cp libtest.so / lib/xzj@xzj-VirtualBox:~/development_test/dynamic_lib_test$ cd / lib/xzj@xzj-VirtualBox:/lib$ lsapparmor hdparm ld-linux.so.2 modules terminfobrltty i386-linux-gnu libtest.so recovery-mode udevcpp ifupdown After linux-sound-base resolvconf ufwcrda init lsb systemd x86_64-linux-gnufirmware klibc-k3La8MUnuzHQ0_kG8hokcGAC0PA.so modprobe.d sysvinit xtables, when you use the ldd command to see whether to use dynamic libraries or not You can see that xzj@xzj-VirtualBox:~/development_test/dynamic_lib_test$ ldd runlinux-vdso.so.1 = > (0x00007ffe8b3fe000) libtest.so = > / lib/libtest.so (0x00007fe6af1f2000) libc.so.6 = > / lib/x86_64-linux-gnu/libc.so.6 (0x00007fe6aee28000) libstdc++.so.6 = > / usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fe6aeaa6000) / lib64/ld-linux-x86-64.so.2 (0x00007fe6af3f4000) libm .so.6 = > / lib/x86_64-linux-gnu/libm.so.6 (0x00007fe6ae79d000) libgcc_s.so.1 = > / lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe6ae587000) when running the executable file directly It worked! Xzj@xzj-VirtualBox:~/development_test/dynamic_lib_test$. / run Welcome to Hubei Welcome to Wuhan Welcome to Xiaogan method 3: dynamic loading.

Dynamic loading is very flexible and relies on a set of standard API provided by Linux. In the source program, you can easily use API to load, use, and release so library resources. The following functions need to include header files when used in code: dlfcn.h

The function prototype shows that const char * dlerror (void) when the operation function of the dynamic link library fails, dlerror can return an error message. The return value of NULL indicates that the operation function has been executed successfully. Void * dlopen (const char * filename, int flag) is used to open the dynamic link library with the specified name (filename) and return the operation handle. When the call fails, a null value is returned, otherwise the operation handle is returned. Void * dlsym (void * handle, char * symbol) returns the execution code address of the function corresponding to the symbol according to the dynamic link library operation handle (handle) and the symbol (symbol). From this address, you can execute the corresponding function with parameters. Int dlclose (void * handle) is used to close the dynamic link library of the specified handle, and only when the usage count of this dynamic link library is 0 will it be actually uninstalled by the system. 2.2 use dynamic link library functions in the program.

Dlsym (void * handle, char * symbol)

Filename: if the name does not start with "/", then the path name is not absolute and the file will be looked up in the following order.

(1) the value of LD_LIBRARY_PATH in user environment variables

(2) dynamic link buffer file / etc/ld.so.cache

(3) Directory / lib,/usr/lib

Flag indicates when to resolve undefined symbols (calls). There are two values:

1) RTLD_LAZY: indicates that it is solved when the function code of the dynamic link library is executed.

2) RTLD_NOW: indicates that all undefined symbols are resolved before dlopen returns. If not, dlopen will return an error.

Dlsym (void * handle, char * symbol)

The general usage of dlsym () is as follows:

Void (* add) (int xreint y); / * explain the dynamic function add to be called * /

Add=dlsym ("xxx.so", "add"); / * Open the xxx.so shared library and take the add function address * /

Add (89369); / * call the add function with two parameters 89 and 369 * / code

# include "my_so_test.h" # include # include # include extern "C" {void (* fn) (void);} int main (int argc, char const * argv []) {void * handle = dlopen (". / libtest.so", RTLD_LAZY); / * const char * err = dlerror (); if (err! = NULL) {perror ("could not open shared object!");} * / if (NULL! = handle) {/ * code * / printf ("nihao\ n") } fn = (void (*) (void)) dlsym (handle, "test_hubei"); fn (); dlclose (handle); return 0;}

Execution result:

Xzj@xzj-VirtualBox:~/development_test/dynamic_lib_test$ gathers + test_hubei.cpp test_wuhan.cpp test_xiaogan.cpp-fPIC-shared-o libtest.soxzj@xzj-VirtualBox:~/development_test/dynamic_lib_test$ gathers +-o mmain_run mmain.cpp-rdynamic-ldlxzj@xzj-VirtualBox:~/development_test/dynamic_lib_test$. / mmain_runnihao Welcome to Hubei! Welcome to Wuhan! Welcome to Xiaogan!

Every time you modify the source file, be sure to regenerate the dynamic file .so, otherwise you will always use the previously produced file. Mistakes that are not conducive to the mode!

3. Compilation parameters

-shared this option specifies that dynamic link libraries (let connectors generate T-type export symbol tables and sometimes weak-link W-type export symbols) are generated without this flag that external programs cannot connect. Equivalent to an executable file

-fPIC: it means that the compiled code is compiled into location-independent code. Without this option, the compiled code is location-dependent, so dynamic loading is to copy the code to meet the needs of different processes, rather than the real sharing of code snippets.

-L.L.: indicates that the library to be connected is in the current directory

-ltest: the compiler has an implicit naming convention when looking for dynamic link libraries, that is, the given name is preceded by lib and followed by .so to determine the name of the library

LD_LIBRARY_PATH: this environment variable indicates the path where the dynamic connector can load the dynamic library.

4. Problems to be paid attention to

There are several problems often encountered when calling a dynamic library. Sometimes, it is obvious that the directory where the header file of the library is located has been entered through the "- I" include, and the file where the library is located is guided by the "- L" parameter, and the name of the "- l" is specified, but when viewed by the ldd command, you cannot find the linked so file you specified. All you have to do at this point is to specify the directory of the dynamic library by modifying the LD_LIBRARY_PATH or / etc/ld.so.conf file. This usually solves the problem that the library cannot be linked.

Parameter when generating a dynamic library-fPIC

-fPIC acts in the compilation phase, telling the compiler to generate location-independent code (Position-Independent Code), then there is no absolute address in the generated code, all using relative addresses, so the code can be loaded into any location in memory by the loader and can be executed correctly. This is exactly what the shared library requires. When the shared library is loaded, the location in memory is not fixed.

Gcc-shared-fPIC-o 1.so 1.c here there is a-fPIC parameter PIC, which is position independent code PIC to make the code snippet of the .so file a real share. if you do not add-fPIC, when the code snippet of the .so file is loaded, the data objects referenced by the code snippet need to be relocated, and the relocation will modify the contents of the code snippet. This causes every process that uses the .so file snippet to generate a copy of the .so file snippet in the kernel. Each copy is different, depending on the location of the .so file code segment and data segment memory mapping.

So compiled without fPIC is relocated according to the loaded location when it is reloaded. (because the code in it is not location-independent) if used by multiple applications, they must maintain a copy of the so code for each program. (because the location where so is loaded by each program is different, obviously the relocated code is different, and of course we can't share it.) We always use fPIC to generate so, and we never use fPIC to generate a. FPIC has basically nothing to do with dynamic links, libc.so can also be compiled without fPIC, but such so must redirect all entries when loaded into the address space of the user's program.

Principle and significance of PIC

Disadvantages of repositioning on load:

(1) the code segment of the dynamic library cannot be shared between processes: multiple processes load the same dynamic library into their different address spaces, resulting in different relocations of the code segments. so in the end, each process that references the dynamic library has a different copy of the dynamic library code segment. (2) the code snippet must be writable, which increases the risk of attack. In order to solve the problem of relocation when loading, the concept of PIC, that is, location-independent code, is introduced. PIC implementation principle: (1) GOT: add GOT (Global Offset Table) to the data segment of the dynamic library, and each item of the table is an absolute mapping of symbols to addresses. Because the offset from the code snippet to the data segment is fixed, you can determine the offset from a symbol in the code snippet to a GOT-specific item at compile time. In this way, the symbol offset in the code snippet can be determined at compile time, and there is no need to modify the contents of the code snippet at load time, just fill in the absolute addresses of the symbols of all items in the GOT of the data segment. Because data segments are not shared between processes, each process has an independent copy, so the design of GOT completely solves the above two problems, thus achieving two purposes: 1, code segments can be shared among multiple processes; 2, code segments are read-only. (2) PLT:PLT is the abbreviation of Program Linkage Table, that is, program link list. The emergence of PLT is for the purpose of delay location. There are often far more functions in a dynamic library than global variables, and fewer functions are called than defined functions. GOT contains the mapping of all global variables in the dynamic library, and resolves the addresses of all global variables when the connector is loaded. If you deal with function call symbols in the same way, it can be very expensive. Therefore, a PLT table is designed in the code snippet, and each item is actually a code snippet, which is used to perform the following logic: on the first access, parse the parameters and fill in the function address to GOT, and the subsequent access directly accesses the function address in GOT. In this way, the purpose of delay positioning is achieved. Therefore, in a dynamic library of PIC, we use GOT to map global variables and PLT+GOT to map function calls, so as to achieve the purpose of code segment reuse and secure access of code segments in the shared library. And that's what PIC is all about. The above is about the content of this article on "how to make Linux static library and dynamic library". I believe we all have some understanding. I hope the content shared by the editor will be helpful to you. If you want to know more related knowledge, please pay attention to the industry information channel.

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.