


What is the connection between libraries and header files in Linux?
The relationship between libraries and header files in Linux: there are declarations of functions in header files, and library files implement the definition of functions; each function in the library needs to be declared in the header file. When writing a program, you need to use header files to provide definitions of constants and declarations of calls to system functions and library functions; and a library is a collection of compiled functions, that is, a collection of target files ".o". It is written according to the principle of reusability and generally consists of a set of interrelated functions to perform a common task.
#The operating environment of this tutorial: linux7.3 system, Dell G3 computer.
In general application source code, there are function declarations in the header file, and library files implement the definition of the function; each function in the library needs to be declared in the header file.
1. Header file
When writing a program, we need to use header files to provide definitions of constants and system functions and libraries Declarations of function calls. These header files are located in /usr/include
. These header files are located in directories that can be automatically searched by the compiler, such as /usr/include/X11 of the X window system and /usr/include /c of GNU C.
When calling gcc, you can use the flag -I
to include header files saved in subdirectories or other non-standard locations, such as gcc -I/usr/openwin/ include fred.c
2. Library file
The library is a collection of compiled functions, that is, the target file A collection of .o is written according to the principle of reusability and generally consists of a set of interrelated functions to perform a common task.
Standard Linux system library files are generally stored in the /lib
and /usr/lib
directories. By default, the GCC linker only searches the standard C language library, which is a historical issue. We must conform the library file name to a specific convention and specify it on the command line.
Library files always start with lib, and then indicate what library it is. The last part .a represents the static function library, and .so represents the shared function library (that is, the DLL dynamic link library under Windows).
Such as gcc -o fred fred.c /usr/lib/libm.a
or gcc -o fred fred.c -lm
# The ##-L flag increases the library search path for the linker, such as
gcc -o x11fred -L /usr/openwin/lib x11fred.c -1X11
##2.1 Static libraryThe static library ends with .a, also called an archive file. When generating an executable program, the static library file is linked in, and the generated executable The file is larger and can be run without the static library file.
2.1.1 Generation methodFirst create two source files fred.c and bill.c
Then use
to compile and generate two target files
Then for these two Write a header file for each function, make a function declaration
Then include the header file in the main function and call one of the library functions
Then compile the main function and link main.o with the previously generated bill.o, which can be executed correctly
Next we generate the library file and use ar to archive the program Create an archive file and add target files to it, which combines several individual files into one large file.
After that we need to use the ranlib
command to generate a content table for the function library.
Then we link the library file with the previously generated program.o file and the execution is successful
Also Use
to specify function libraries, and -L
to specify non-standard locations.
nm command to view which functions are included in the target file, function library or executable file Comparison of static libraries between Linux and Windows When many applications are running at the same time and they all use functions from the same function library, there will be many copies of the same function in the memory, which wastes memory. And external storage! ! When a program uses a function library, it no longer contains function code when linking, but refers to shared code accessible at runtime. When the compiled program is loaded into memory for execution, the function reference is parsed and A call is made to the shared library, and if necessary, the shared library is loaded into memory. That is, the system can keep only one copy of the shared library in memory for many applications to call, or it can keep only one copy in external memory. Moreover, shared libraries can be updated independently of the applications that rely on them, and the applications do not need to be recompiled. Use the intermediate file bill.o fred.o to generate the shared library libfoo.so After the shared library is generated, it must be placed in the standard search directory. Additional locations for searching shared libraries can be configured in the file Then specify the search path Link to generate executable file lddTools can be used for analysis Shared libraries required to run the executable file You can also specify the search path of the .so library when compiling the target code, through the gcc parameter Related recommendations: "Linux Video Tutorial", available For disassembly analysis. When a program is created, it only contains the functions it actually needs in the function library. Although there are declarations of all functions in the header file, the linker will not link them all in.
2.2 Shared library
In a Linux system, the program (dynamic loader) responsible for loading shared libraries and parsing functions referenced by client programs is ld.so
2.2.1 Generation method
gcc -shared -fpic -o libfoo.so bill.o fred .o
/etc/ld.so.conf
. After modifying this file, execute the command ldconfig
to process it. The content of /etc/ld.so.conf
is include /etc/ld.so.conf.d/*.conf
, create your own dynamic in this directory Link library path configuration filemylib.conf
gcc -o main program.o -lfoo -L.
-Wl,- rpath
is specified, such as gcc main.cpp -lfoo -L. -Wl,-rpath=.
-Wl, which means that the following parameters will be passed to the link program ld (because gcc will automatically call ld) When specifying multiple dynamic library search paths, separate the paths with colons ":".
The above is the detailed content of What is the connection between libraries and header files in Linux?. For more information, please follow other related articles on the PHP Chinese website!

Hot AI Tools

Undresser.AI Undress
AI-powered app for creating realistic nude photos

AI Clothes Remover
Online AI tool for removing clothes from photos.

Undress AI Tool
Undress images for free

Clothoff.io
AI clothes remover

AI Hentai Generator
Generate AI Hentai for free.

Hot Article

Hot Tools

Notepad++7.3.1
Easy-to-use and free code editor

SublimeText3 Chinese version
Chinese version, very easy to use

Zend Studio 13.0.1
Powerful PHP integrated development environment

Dreamweaver CS6
Visual web development tools

SublimeText3 Mac version
God-level code editing software (SublimeText3)

Hot Topics



The key differences between CentOS and Ubuntu are: origin (CentOS originates from Red Hat, for enterprises; Ubuntu originates from Debian, for individuals), package management (CentOS uses yum, focusing on stability; Ubuntu uses apt, for high update frequency), support cycle (CentOS provides 10 years of support, Ubuntu provides 5 years of LTS support), community support (CentOS focuses on stability, Ubuntu provides a wide range of tutorials and documents), uses (CentOS is biased towards servers, Ubuntu is suitable for servers and desktops), other differences include installation simplicity (CentOS is thin)

CentOS has been discontinued, alternatives include: 1. Rocky Linux (best compatibility); 2. AlmaLinux (compatible with CentOS); 3. Ubuntu Server (configuration required); 4. Red Hat Enterprise Linux (commercial version, paid license); 5. Oracle Linux (compatible with CentOS and RHEL). When migrating, considerations are: compatibility, availability, support, cost, and community support.

CentOS installation steps: Download the ISO image and burn bootable media; boot and select the installation source; select the language and keyboard layout; configure the network; partition the hard disk; set the system clock; create the root user; select the software package; start the installation; restart and boot from the hard disk after the installation is completed.

How to use Docker Desktop? Docker Desktop is a tool for running Docker containers on local machines. The steps to use include: 1. Install Docker Desktop; 2. Start Docker Desktop; 3. Create Docker image (using Dockerfile); 4. Build Docker image (using docker build); 5. Run Docker container (using docker run).

Docker uses Linux kernel features to provide an efficient and isolated application running environment. Its working principle is as follows: 1. The mirror is used as a read-only template, which contains everything you need to run the application; 2. The Union File System (UnionFS) stacks multiple file systems, only storing the differences, saving space and speeding up; 3. The daemon manages the mirrors and containers, and the client uses them for interaction; 4. Namespaces and cgroups implement container isolation and resource limitations; 5. Multiple network modes support container interconnection. Only by understanding these core concepts can you better utilize Docker.

Docker process viewing method: 1. Docker CLI command: docker ps; 2. Systemd CLI command: systemctl status docker; 3. Docker Compose CLI command: docker-compose ps; 4. Process Explorer (Windows); 5. /proc directory (Linux).

VS Code system requirements: Operating system: Windows 10 and above, macOS 10.12 and above, Linux distribution processor: minimum 1.6 GHz, recommended 2.0 GHz and above memory: minimum 512 MB, recommended 4 GB and above storage space: minimum 250 MB, recommended 1 GB and above other requirements: stable network connection, Xorg/Wayland (Linux)

Troubleshooting steps for failed Docker image build: Check Dockerfile syntax and dependency version. Check if the build context contains the required source code and dependencies. View the build log for error details. Use the --target option to build a hierarchical phase to identify failure points. Make sure to use the latest version of Docker engine. Build the image with --t [image-name]:debug mode to debug the problem. Check disk space and make sure it is sufficient. Disable SELinux to prevent interference with the build process. Ask community platforms for help, provide Dockerfiles and build log descriptions for more specific suggestions.
