"Dynamic Library" and "Static Library" in Linux system the suffix of the/etc/ld.so.conf dynamic library is *.so the suffix of the static library is libxxx.a ldconfig directory name

"Dynamic Library" and "Static Library" in Linux system the suffix of the/etc/ld.so.conf dynamic library is *.so the suffix of the static library is libxxx.a ldconfig directory name

Reprinted from: http://blog.chinaunix.net/uid-23069658-id-3142046.html

Today we mainly say that the Linux system is based on dynamic libraries (. So) and static (. A) programs that are tricky. Before we do that, we need to look at what magical and wonderful things happen between the source code and the executable program.
In the Linux operating system, the use of elf format as an executable program or program in the process of intermediate format. The ELF (executable and linking format, executable connection format) is a UNIX system lab (USL) developed and published as an application binary interface (application Binaryinterface,abi) . Tool Interface Standard Committee (TIS) selected the evolving Elf standard as a portable binary file format for working with different operating systems on 32-bit Intel systems. This article does not explain the elf file format and its composition too much, so as not to dilute the theme of this article, as long as you know the concept of the line. Later, we will explain the ELF format in Linux. The conversion of the source code to the executable program needs to go through the process as shown:

Win9x and win Nt/2000/xp 32-bit executable PE (portable executable: Removable executable file)

Compilation is the process of converting a program written in a high-level language into an assembly language program of the appropriate processor. In essence, compiling is a process of converting text. In the case of embedded systems, it is common to convert programs written in C into the assembly code of the processor. The compilation process contains the syntax parsing of C language and the generation of sink code two steps. Compilation is usually done one file at a time, and for each file written in the C language, preprocessing may be required.
Assembly is the process of generating binary code (machine code) of the target system from an assembly language program. Machine code generation is closely related to the processor. The process of compilation is relatively simple, relative to the parsing of the compilation process. This is because for a specific processor, its assembly language and binary machine code is one by one corresponding. The assembly process input is the assembly code, this assembly code may be derived from the output of the compilation process, or can be directly written in assembly language program.
L connection refers to assembling the assembly-generated multi-segment machine code into an executable program. In general, each source file will generate a target file through the compilation and compilation process. The purpose of a connector is to combine these target files, which include the merging of sections such as code snippets, data segments, and the addition of corresponding file headers.
GCC is the main program generation tool under Linux, which includes some auxiliary tools in addition to compilers, assemblers, and connectors. In the following analysis, I will teach you the basic use of these tools, the power of Linux is that for the less understood command or function, there is a very powerful "man" moment stand by your side, what will not go to command line terminal input: Man [command name or function name], Then the Divine lamp will come to an apparition.
How does the operating system react to the last compiled executable program when we execute it? Let's start with a general grasp of the macro, 2 shows:

As a Unix operating system, the Linux operating system provides a series of interfaces called System call. In the UNIX philosophy, system calls "provide a mechanism, not a policy." The library function of C language is implemented by invoking the system call, and the library function provides the interface of the C language library file to the upper layer. At the application layer, functions are implemented by invoking the C library functions and system calls. In general, applications mostly use C-Library functions to implement their functions, with fewer system calls.
So what exactly is the final executable file like? As we have already said, here we do not delve into the format of the elf file, just give it a structure diagram and some simple instructions to make it easy for everyone to understand.
The elf file format consists of three main types: executable, target, shared.
1. Executable file (application)
Executable files contain code and data and are programs that can be run directly.
2. Target file (*.O)
A relocatable file, also known as a target file, contains code and data that are used when connecting with other relocation files and shared object files.
The *.O file participates in the program's connection (creating a program) and the execution of the program (running a program), which provides a convenient and efficient way to view the contents of the file in a parallel perspective, and the activities of these *.O files can reflect different needs.
Under Linux, we can compile the source file with Gcc-c to compile it into *.O format.
3. Shared Files (*.so)
Also known as a dynamic library file, it contains code and data that are used by the connector LD and the runtime Dynamic Connector at the time of connection. Dynamic connectors may be called ld.so.1,libc.so.1 or ld-linux.so.1. The file in my CentOS6.0 system is:/lib/ld-2.12.so

An elf file is a collection of sections from the point of view of the connector (Linker); From the point of view of the program loader (Loader), it is a collection of segments (segments). Elf-formatted programs and shared libraries have the same structure, except that the collection of segments and the collection of sections are somewhat different.
So what exactly is a library?
A library is essentially a binary format of executable code that can be loaded into memory for execution. There are two kinds of library, static library and dynamic library.
Static libraries: the names of such libraries are typically libxxx.a,xxx for the library. The use of the static function library compiled into a larger file, because the entire library of all the data will be integrated into the target code, his advantage is obvious, that the compiled execution program does not require external library support, because all the functions used have been compiled. This, of course, will also be a disadvantage, because if the static library changes, then your program must be recompiled.
Dynamic libraries: The names of such libraries are generally libxxx. m.n.so, the same xxx is the name of the library, M is the main version number of the library, N is the library's sub-version number. Of course, you can not have the version number, but the name must have. Compared to the static function library, the dynamic function library is compiled without being compiled into the target code, and your program executes to the relevant function to invoke the corresponding function in the library, so the dynamic function library produces less executable files. Since the library is not integrated into your program, it is applied and invoked dynamically while the program is running, so you must provide the appropriate library 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 storing the appropriate libraries, such as/lib/usr/lib.
when you want to use a static library, the connector finds the functions required by the program, and then copies them to the execution file, because the copy is complete, so once the connection is successful, the static library is no longer needed.。 HoweverThis is not the case with dynamic libraries. The dynamic library leaves a tag inside the executor that indicates that the library must first be loaded when the program executes。 Due to the space saving of the dynamic library, the default operation to connect under Linux is to connect the dynamic library first, that is, if both static and dynamic libraries exist and are not specifically specified, they will be connected to the dynamic library.

OK, with all this knowledge, then you can figure out what I'm doing. All say examples are the best teachers, let's start with examples.
1. Static link library
Let's first make our own static link library and then use it. The GCC and AR commands are used in the process of making a static link library.
Prepare two libraries of source files st1.c and st2.c, use them to make library libmytest.a, as follows:

File/usr/bin/pkg-config
/usr/bin/pkg-config: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (Uses share D Libs), for Gnu/linux 2.6.18, stripped

The static library file libmytest.a has been generated, viewing its properties with the file command and discovering that it is indeed an archive compressed file. With ar-t libmytest.a You can view a static library that contains those obj files:

Next we write a test program to call the two interfaces Print1 () and Print2 () provided in the library LIBMYTEST.A.

See, Static Library writing and invocation is so simple, learn it. Here the GCC parameter-L is to tell the compiler that the path to the library file is the current directory, and-L is to tell the compiler to use the name of the library called MyTest.

2. Dynamic Library
The existence of a static library *.a file exists primarily to support an older executable file in a.out format. The most used is the number of dynamic libraries.
The suffix of the dynamic library is *.so. Most of the dynamic libraries in the Linux distribution are basically located in the/usr/lib and/lib directories. Before developing and using our own dynamic library, please allow me to start by nagging you about Linux and the dynamic library.
Sometimes when our application does not work, it prompts us to say that it cannot find a library, or that the version of the library does not fit its appetite, and so on. So how does the application know which libraries are needed? We've had a couple of great commands in front of us. LDD, which is used to see if a file depends on those so library files.
The configuration file of a dynamic link library in a Linux system is usually within the /etc/ld.so.conf file, and it contains the name of the directory where the dynamic libraries that can be shared by Linux are located. In my system, the contents of the file are as follows:

Then the/etc/ld.so.conf.d/directory contains a lot of *.conf files, as follows:

Each of these conf files represents a library configuration for an application, with MySQL as an example:

If you are the same as I installed the CentOS6.0 system, then the attentive reader may find that in the/etc directory, there is a file called Ld.so.cache. From the name point of view, we know that it must be a dynamically linked library of what cache files.
Yes, you're right. In order for the dynamic link library to be used by the system, when we modify any file in the/etc/ld.so.conf or/etc/ld.so.conf.d/directory, or when we copy a new dynamic link library file to those directories,need to run a very important command: Ldconfig, the command is located in the/sbin directory, the main purpose is to search for/lib and/usr/lib, as well as the configuration file/etc/ Search for the available dynamic link library files in the directory listed in Ld.so.conf, and then create the connection required by the dynamic loader/lib/ld-linux.so.2 and (default) cache file/etc/ld.so.cache ( This file holds the list of dynamically linked library names that are already in order.。
In other words: When the user creates or copies a dynamic link library under a directory, if you want to make it shared by the system, you can executeThe "ldconfig directory name" command。 The function of this command is to allow Ldconfig to share the dynamic-link library under the specified directory with the system, that is, to append the shared library in the cache file/etc/ld.so.cache to the specified directory. 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 library under this directory may not be shared by the system when you run Ldconfig again. When running ldconfig alone, it searches only for/lib,/usr/lib, and directories listed in the/etc/ld.so.conf file, and uses them to reconstruct/etc/ld.so.cache.
As a result, we can either copy it to the/lib,/etc/lib directory later, or modify the/etc/ld.so.conf file to add our own library path to the file, and then execute the ldconfig command.
Non-long time kung Fu, finally put the foundation to play well, monkey anxious you already according to resist the passion of want to try it! Ha ha... OK, say the whole we will open the whole, then I will lead you to develop their own dynamic library, and then teach you how to use it.
We have a header file My_so_test.h and three source files test_a.c, TEST_B.C, and TEST_C.C, and they are made into a dynamic-link library file named libtest.so:

OK, everything is ready, only owed the East wind. How do you compile these files into a so file that we need? It can be done in two steps or one step:
Method One:
1. As a target. o File:

2. Re-generate so file:

-shared This option specifies to generate a dynamic connection library (let the connector generate the export symbol table of type T, and sometimes the export symbol of the weakly connected W type) without which the external program cannot connect. Equivalent to an executable file.
-fpic: represents compiled to a location-independent code, without this option, the compiled code is location-dependent, so dynamic loading is a way of copying code to meet the needs of different processes, but not to achieve the purpose of real code segment sharing.
Method Two: One step in place.

At this point, we made the dynamic library file libtest.so even if it's done.

The next step is how to use the dynamic library. There are two ways to use dynamic-link libraries: They can be dynamically linked at run time, and they can be dynamically loaded in the program. Next, I'll describe each of these two methods.

+ + + Dynamic Library usage + + +
Usage one: dynamic linking.

Use the "-ltest" flag to tell the GCC driver to reference the shared function library libtest.so during the connection phase. "-L." The tag tells the GCC library that it might be in the current directory. Otherwise, the GNU Connector will look for the standard system functions directory.
Here we note that the output of ldd it says our libtest.so it has not been found. Remember when I was in front of the dynamic Link library section at the beginning of the pile of nagging, now you should be very clear why it. Because our libtest.so is neither in/etc/ld.so.cache nor in any of the directories specified by/lib,/usr/lib, or/etc/ld.so.conf. What to do? You still use me to tell you? Whatever you do, anyway, I used the ldconfig ' pwd ' to fix it:
The results of the implementation are as follows:

I can't help but also wordy, believe me, my nagging is good for everyone. Why should I use this method? Because I'm showing you the usage of the dynamic library, I'll delete the libtest.so after it's done, and then refactor the Ld.so.cache, without any impact on my system. If I was to develop a software, or to my own system DIY a very useful function module, then I would prefer to copy libtest.so to/lib,/usr/lib directory, or I may also be in the/usr/local/lib/directory to create a new folder XXX, Copy the so library to there and create a new file mytest.conf in the/etc/ld.so.conf.d/directory with only one line of "/usr/local/lib/xxx/libtest.so" and then execute ldconfig. If you do not understand how to solve the "not found" problem, then it should be understood now.
Method two: Dynamic loading.
Dynamic loading is very flexible, and it relies on a set of standard APIs provided by Linux to complete. In the source program, you can easily use the API to load, use, release so library resources. The following function is used in the code to include the header file: Dlfcn.h
Function prototypes
Description
const char *dlerror (void)
When the dynamic link library operation function fails, Dlerror can return an error message, and a return value of NULL indicates that the operation function executed successfully.
void *dlopen (const char *filename, int flag)
A dynamic-link library that opens the specified name (filename) and returns an action handle. When the call fails, a null value is returned, otherwise the action handle is returned.
void *dlsym (void *handle, char *symbol)
The execution code address of the function that corresponds to the symbol is returned according to the dynamic Link library operation handle (handle) and the symbol. From this address, the corresponding function can be executed with parameters.
int dlclose (void *handle)
The dynamic-link library used to close the specified handle, which is actually unloaded by the system only if the usage count for this dynamic-link library is 0 o'clock. 2.2 Use dynamic link library functions in your program.
Dlsym (void *handle, char *symbol)
FileName: If the name does not start with "/", then the non-absolute pathname will find the file in the following order of precedence.
(1) The Ld_library value in the user environment variable;
(2) Dynamic Link buffer file/etc/ld.so.cache
(3) Catalogue/lib,/usr/lib
Flag indicates when undefined symbols (invocations) are resolved. There are two values:
1) Rtld_lazy: Indicates that the function code of the dynamic link library is resolved when it executes.
2) Rtld_now: Indicates that all undefined symbols are resolved before Dlopen returns, and Dlopen will return an error once it is not resolved.
Dlsym (void *handle, char *symbol)
The usage of dlsym () is generally as follows:
void (*add) (int x,int y);/* Describes the dynamic function to invoke add */
Add=dlsym ("xxx.so", "add");/* Open xxx.so Shared library, take add function address */
Add (89,369);/* with two parameters 89 and 369 Call the Add function */
Look at my moves:

Execution Result:

Use the dynamic link library, the source program to include the Dlfcn.h header file, write the program attention Dlopen functions such as the correct call, compile with the-rdynamic option and-LDL option (otherwise the compilation will not pass), to produce a call to the dynamic link library execution code.
OK, through the guidance of this article, practice believe that you should have a little understanding of the Linux library mechanism, the most important thing is to develop the use of library files. Due to my limited knowledge, some of the views in the text if not in place or understand the wrong place also ask you to advise.

"Dynamic Library" and "Static Library" in Linux system the suffix of the/etc/ld.so.conf dynamic library is *.so the suffix of the static library is libxxx.a ldconfig directory name