Use System library files in Linux to reduce work

Linux uses system library files to reduce work-Linux general technology-Linux programming and kernel information. The following is a detailed description. In different development environments, sub-database files are often provided. Library files are code or programs that implement a specific function. You can use it directly when developing an application. This reduces the development workload. In Linux, a wide range of library files are also provided. Therefore, if the Linux operating system developers can learn to use this library file, the workload can be greatly reduced. Specifically, the Linux system administrator needs to understand three aspects. First, common library files, second, library file calling methods, and third, why is shared library recommended. With this knowledge, the system administrator can call the library files during program development. The system administrator can refer to relevant books for details about the content contained in the library files. I will not elaborate too much here. I will only talk about the calling methods of library files and the differences between them to help readers determine whether static databases or dynamic libraries are used.

1. Method of calling the library file.

Library files can be used to hide specific implementations. If the system administrator uses this library file, only the header file containing the required function is required. Instead of the specific implementation of the function. This is like making a phone call. The system administrator only needs to know how to use a mobile phone to call the phone, instead of how the internal lines are arranged, and how the signals are transmitted directly on two mobile phones, no need to know how digital signals are converted into voice signals. In addition, the use of library files can reduce the development workload. Some functions may be used in multiple applications, so you do not need to rewrite the code and compile it through the library file. Therefore, the development workload can be greatly reduced.

How can the system administrator call the library file? In the development environment of the Linux operating system, there are two calling methods. One is the call method called static library. That is, during compilation, the binary image code of the corresponding function in the library is directly copied to the current compiled program. Simply put, you can directly copy and paste the code to reduce code development. This is the same way that some people make up for each other when writing a document. In Linux, if the library file is suffixed with. a, it is represented as a static library file. When this static library file is used, the system administrator can open the library file in the editor, copy the code to his own application, and compile it.

The second method is shared library call. If you use this method to call the library file, you only need to reference the binary impression code entry location of the corresponding function in the library during compilation. Then, the application reads the function code from the shared library file at runtime to realize indirect reference. That is to say, this shared library is like a living room. As long as the user opens a door between the room and the living room, the room can be used. Static databases are different. If the static library wants to use the living room, he does not open a door between the room and the living room, but includes the living room into his room and integrates with the room. Therefore, these two call methods differ greatly in the implementation mechanism. This also determines their respective advantages and disadvantages. When using these library files, the system administrator has to pick up their respective advantages and disadvantages, and then select an appropriate call method.

Ii. Advantages of shared libraries.

The advantage of using static library calling methods is obvious. Because the code of the static file has been integrated with the code developed by the user, you do not need to find the path of the library when executing this application. In this case, no database support is required for executing the executable file. However, its disadvantages are also obvious. If this library file is required for multiple subprograms of this application, you need to copy multiple pieces of the same Code. At this time, the length of the Code will undoubtedly increase and the maintenance difficulty will be increased. The most terrible thing is that it also has a negative impact on the performance of the application. To this end, you can use a static library unless the application you develop is simple and only provides a single function. In addition, I suggest you use a shared library. Specifically, the use of shared libraries can bring about the following advantages.

First, upgrade and maintain shared library files. Files in the shared library may also be faulty. You need to upgrade the library file to solve the problem. If a static library is used, you have to change the code that references the library file one by one. When an application is referenced for ten times, it needs to be changed to ten places. Obviously, the subsequent maintenance workload will be huge. However, if shared library files are used, they are different. In this case, you only need to change the library file in the shared library. The application code only specifies the location where the library file is stored. As long as the location of the database does not change, the code in this application does not need to be changed. Therefore, if files in the shared library need to be upgraded due to errors or other reasons, the application will not be affected at all. In this case, you only need to overwrite the database file without re-compiling the application code. This is like the difference between SIM card and SIM-free PHS. If you want to change your phone number, you only need to change the SIM card for PHS with a SIM card. For PHS without SIM card, you need to replace the whole PHS. This PHS with a SIM card is like a shared library, but not a SIM card.

Is to improve code sharing. When multiple subroutines in an application need to use the same library file, the Linux operating system transfers the shared library file to the memory unit. No matter how many subprograms need to use the same code, you only need to put the code in the shared memory, instead of loading it directly into the executable file in all places like the static library. This is similar to watching movies. Using a shared library is like watching a movie in a cinema. A movie is shown only once, but many people can watch it together. Using static libraries is like watching movies in your own cinema. If three families want to watch the same movie, they have to open their own cinemas in their own homes. Undoubtedly, the utilization rate of the home theater is not high, at least not as high as the equipment in the cinema. At the same time, this will increase the system load. Each household uses its own cinema. If the three families are in use, the power consumption will be two times more. Therefore, using a shared library can greatly save system resources, especially memory overhead, which can make the application program run faster. The more complex the application to be developed or the more likely it is to use the same code, the more obvious the performance improvement.

However, this shared library file has a major defect, that is, the executable file has a certain dependency with the library file. If an executable file uses a shared library, it calls a library file. However, when this executable program runs on other Linux operating systems, it is likely that the library file does not exist or the version is relatively low, in this case, the executable file may fail to run or an error may occur. To avoid this situation, you sometimes have to distribute the library files you need with executable files. In addition, in code writing, you must specify the search location of the library file. Otherwise, the application cannot find the location of the library file during execution.

However, all the defects referenced by this shared library can be solved. To this end, these defects are insufficient. As long as necessary verification is performed before software packaging or software installation, the negative impact of this defect on the application can be avoided. In general, we recommend that you use shared libraries to call library files. Especially when designing large applications or applications that may have performance bottlenecks, using a shared library will help the system administrator improve the performance of applications.