Search Path for C header files and library files

I. Discussion Environment
* Operating System: Redhat5/Fedora14

* Compiler: gcc 4.5.1

The following remarks are only applicable in the above environments. In other environments, we can draw inspiration from analogy.

 

Ii. Search Path for C header files
C language, using the include command, including header files, but further subdivided into two forms:

1. Form 1: # include "file1"
Gcc first searches for file1 in the current directory (the directory where the source file containing this # include command is located). If it cannot be found, it continues with the-iquote option (if any) find file1 in the specified directory.

For example, in the file/usr/include/sys/stat. h contains the command # include "types. h ", then gcc first looks for types in the/usr/include/sys directory. h file. Well, there is indeed a types. h file in this directory. Now let's move this file to another directory: mv/usr/include/sys/types. h/bar/foo/. during compilation, you can use the-iquote option without changing stat. in the case of h, normal compilation (of course, it is generally not recommended to do so ):

Gcc-iquote/bar/foo-I/usr/include/sys *. o

2. Form 2: # include <file2>
Gcc looks for file2 in the following order:

-Idir1-Idir2...
/Usr/local/include
Libdir/gcc/<target>/<version>/include
/Usr/<target>/include
/Usr/include
In the first line,-Idir1-Idir2... is the directory specified by the user through the-I option of gcc. It is worth mentioning that the header files placed under/usr/local/include/will also be automatically retrieved by gcc, this is different from the library Processing Method in the/usr/local/lib/directory (the gcc linker does not automatically find the library files in this directory during runtime, ).

 

Iii. Search Path for C language library files
The search path of the C language library file is divided into two phases: the link stage and the runtime stage.

1. link time)
At this stage, you need to tell the compiler where to find the library file? Link library files in static or dynamic mode? By default, dynamic links are used. This requires that the corresponding. so dynamic library file exists. If not, find the corresponding. a static library file. If you pass the-static option to gcc during compilation, the static link is used. This requires that all library files have a corresponding *. a static library.

So can some libraries use dynamic links and other libraries use static links? Not sure. Please refer to the ld user manual. I have never used it like this.

In the link phase, how does the gcc compiler find library files (linker itself does not have the default search path, which is passed to linker by gcc )? During compilation, you can add the-v option to gcc to observe the library file search path it passes to the linker (observe the value of the LIBRARY_PATH variable). The common search path is as follows:

Any directory specified by-rpath-link or-rpath
LD_RUN_PATH (if the-rpath or-rpath-link option is not found)
-Ldir1-Ldir2...
/Usr/lib/gcc/<target>/<version>/
/Usr/lib/
The difference between the-rpath-link option and the-rpath option in the first line is that the directory specified by the-rpath option is hardcoded into the executable file, -The directory specified by the rpath-link option takes effect only in the link phase. Since both options are the options of the linker ld, how do I pass these two options to the ld from gcc? The method is as follows (For details, refer to the-Wl option of gcc ):

Gcc-Wl,-rpath,/usr/local/lib

This is equivalent to passing the following parameters to the ld:

Ld-rpath/usr/local/lib

In the second row, if the-rpath or-rpath-link option is not set, find the directory specified by the LD_RUN_PATH environment variable and treat it as the-rpath option. Row 3-Ldir1-Ldir2 ..., it is the path for finding the specified library file through the-L option of gcc. The search order is based on the-L parameter we passed to search from left to right; the fourth row belongs to the gcc library directory; the fifth line/usr/lib/is the directory of the default system library file in Linux. Fourth, the fifth line is the directory that gcc automatically sends to linker. For example, on my current machine, using gcc-v, we can see that the value of LIBRARY_PATH is:

LIBRARY_PATH =/usr/lib/gcc/i686-redhat-linux/4.5.1/:/usr/lib/

But this is not all truth! Based on my own tests, I found that gcc will also use the/usr/local/lib/directory as the path for searching in the Link stage. This is the root cause of the problem-during the link process, some library files in/usr/local/lib/are used, but they are not found in the runtime stage.

2. runtime)
Only when the executable program uses a dynamic method to link the library file will there be a problem of searching the library file during runtime. For such an executable program, it only records the name of the dynamic library. Therefore, when running this program, the operating system loader (ld. so) needs to load the library file to the memory according to the library name and when necessary.

In linux, the path for finding a dynamic library (also called a shared library) is as follows:

-Directory specified by the rpath option (hard-coded to the executable file)
LD_LIBRARY_PATH
/Lib or/usr/lib
Default search path
You can use readelf to view the rpath in the hardcoded executable file:

$ Readelf-d <Executable File Name> # Display the dynamic section (if present)

LD_LIBRARY_PATH does not have this problem, but we generally do not recommend using this environment variable, because modifying this variable affects all programs dependent on this environment variable (if you have to use it, write this environment variable in the startup script and make it only affect the program in the script ).

What is the default search path? In Redhat5/Fedora14, ld. so read/etc/ld. so. cache file to find the location of the library file, if not found, continue from/etc/ld. so. find the specified directory in the conf file. This ld. so. cache file is equivalent to a key-value database. The key is the name of the dynamic database, and the value is the storage path of these databases.

So how is the/etc/ld. so. cache file generated? This involves the ldconfig tool. Ldconfig is a configuration tool for dynamic link libraries. It can be used to update/etc/ld. so. cache file, you can also view the key-value information in this file (using ldconfig-p), ldconfig usage details, please refer to its user manual. To sum up the default system search path:

/Etc/ld. so. cache
The directory specified in the/etc/ld. so. conf file
Iv. References
Man ld
Man ldconfig
Html> http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html
Http://www.eyrie.org /~ Eagle/notes/rpath.html