# #Preface
When we install source code on the Linux platform, we often encounter the output information of .so and .o files. Generally speaking, we only need to take a glance at the output information of these files and do not need to explore in depth. But if we need to write the source code ourselves and compile it manually, we need to have an in-depth understanding of this information.
File explanation
The .so, .o, and .a files in Linux actually correspond to the obj, lib, dll, exe and other files in Windows. Before explaining these files in Linux, let's first talk about the role of these files in Windows.
The relationship between obj, lib, dll and exe under windows
exe is the suffix of the executable program we usually know, while obj, lib and dll are the key files that constitute the running program . lib corresponds to dll. lib is the library file of the static link library, and dll is the library file of the dynamic link library.
The so-called static means that when linking, extract the necessary things and arrange them into your exe file. When you run your exe in the future, you no longer need lib. The so-called dynamic means that when the exe runs, it depends on the functions provided in the dll. Without this dll, your exe cannot run.
lib, dll, and exe are all considered final target files and final products. And c/c belongs to the source code. The transition between the source code and the final target file is the intermediate code obj. In fact, the reason why the intermediate code is needed is that you cannot get the target file at one time.
For example, an exe needs to generate many cpp files. The compiler can only compile one cpp file at a time. In this way, after the compiler compiles a cpp, it will be compiled into obj. When all necessary cpp are compiled into obj, they will be unified and linked into the required exe. It should be said that the lack of any obj will cause the exe link to fail.
obj stores compiled code and data with names, so unresolved external symbol problems sometimes occur during connection. When connected into an exe, there is no concept of name, only an address. lib is a combination of a bunch of obj.
Theoretically, you can connect obj files to reference other projects (you can think of an obj file as equivalent to the cpp file that compiles and generates it. You can reference obj to replace cpp, or you can add cpp to replace obj), but in practice Lib is usually used to implement mutual references between projects.
The compiler will link some commonly used libraries by default, and you need to specify others by yourself.
The difference between lib and dll
lib is needed when compiling, and dll is needed when running. If you want to complete the compilation of source code, lib is enough. If you want to make dynamically linked programs run, a dll is enough. During the development and debugging phases, it is of course best to have both.
General dynamic library programs include lib files and dll files. The lib file must be connected to the application during compilation, while the dll file is only called during runtime. If there is a dll file, the corresponding lib file is generally some index information, and the specific implementation is in the dll file. If there is only a lib file, then this lib file is statically compiled, and the index and implementation are in it.
The statically compiled lib file has advantages: there is no need to install dynamic libraries when installing them to users. But there are also disadvantages, which is that the application is relatively large and the flexibility of the dynamic library is lost. When the version is upgraded, a new application must be released at the same time.
In the case of a dynamic library, there are two files, one is the import library (.LIB) file (actually it is also a static library, but only the function can be linked to the entry of the dll during linking exe, instead of actually linking the function body into the exe like a real static link library, dynamic linking through lib is actually implemented using static linking), one is a dll file, and the imported library file contains the files exported by the dll The name and location of the function. The dll contains the actual functions and data. The application uses the LIB file to link to the dll file it needs to use. The functions and data in the library are not copied to the executable file.
Therefore, in the executable file of the application, what is stored is not the function code being called, but the memory address of the function to be called in the dll. In this way, when one or more applications are running, the program code and the function being called are stored. The called function codes are linked together, thus saving memory resources. As can be seen from the above description, dll and .LIB files must be distributed with the application, otherwise the application will generate errors.
Functions in dll are divided into two types:
dll exported functions can be called by applications;
dll internal functions can only be used in dll programs, applications Unable to call them
The difference between .o, .a, and .so files under Linux
.o is a target file, which is equivalent to the .obj file in Windows.
.so is a shared library, a shared object, used for dynamic connection, equivalent to a dll under Windows, and an executable file in Linux.
.a is a static library. To put it bluntly, it is a bunch of .o put together for static connection. The effect is the same as .o.
Static function library
Features: It is actually a collection of simple ordinary target files, which are added to the target program before the program is executed.
Advantages: Compatible with some previous programs; simple description; allows programmers to link programs without recompiling the code, which means no external function support is needed, saving the time of recompiling the code ( This advantage is no longer obvious); developers can also keep the source code confidential.
The name of this type of library is generally libxxx.a. The file compiled using a static function library is relatively large, because all the data of the entire function library will be integrated into the target code.
Disadvantages: If the static function library changes, your program must be recompiled.
Shared function library
The shared function library is loaded when the executable program starts, and the functions in the shared function library can be automatically loaded when all programs are re-run. Compared with static function libraries, shared function libraries are not compiled into the target code during compilation.
The corresponding function in the shared function library is only called when the program executes the relevant function, so the executable file generated by the shared function library is relatively small. Since the shared function library is not integrated into your program, but It is dynamically applied for and called when the program is running, so the corresponding library must be provided in the running environment of the program.
Changes to the shared function library do not affect your program, so it is more convenient to upgrade the shared function library.
Related recommendations: "Linux Video Tutorial"
