Organize the problems related to the search path of header files and library files in the GCC compilation of Linux

Organize the problems related to the search path of header files and library files in the GCC compilation of Linux

Category: makefile/make/gcc/ld2010-11-20 23:15 535 people read reviews (0) Favorite reports

Transfer words: This article details the GCC compile-time Search header file path and mode, compile the way to find Lib library, and run-time loading library search!!! It's very classic! New knowledge will be summed up here in the future!

In the cross-compilation we need to use other libraries, in the config time can be "-i" to specify the header file directory, but each time it is necessary to set up a bit of trouble, find a simple method.

Look at the red section below.

There are a number of environment variables that can be set to affect how GCC compiles the program. The control of these variables can also be used with the appropriate command-line options. Some environment variables are set in the list of directory names. These names are used in the same format as the PATH environment variable. The special character path_separator (defined when the compiler is installed) is used between directory names.

In UNIX systems, delimiters are colons, while Windows systems are semicolons.

C_include_path Use this environment variable when compiling a C program. This environment variable specifies one or more list of directory names, looking for header files as if the-isystem option was specified on the command line . All directories specified by-isystem are looked up first. ==> also see CPath, Cplus_include_path and Objc_include_path.

Compiler_path the environment variable specifies one or more directory name lists, and if you do not specify a Gcc_exec_prefix locator subroutine, the compiler will look for its subroutines here. ==> also see Library_path, Gcc_exec_prefix and-B command line options.

CPath Use this environment variable when compiling C, C + +, and objective-c programs. This environment variable specifies one or more list of directory names, looking for header files as if specifying the-l option on the command line. All directories specified by-L are first found. ==> also see C_include_path, Cplus_include_path and Objc_include_path.

Cplus_include_path uses this environment variable when compiling a C + + program. This environment variable specifies one or more list of directory names, looking for header files as if the-isystem option was specified on the command line. All directories specified by-isystem are looked up first. ==> also see CPath, C_include_path and Objc_include_path.

Dependencies_output Setting this environment variable for the file name causes the preprocessor to write to the file based on the makefile rule of the dependency. The system header file name is not included. If the environment variable is set to sole name, it is considered a file name, and the name of the dependency rule comes from the source file name. If there are two names in the definition, the second name is the target name to use as the dependency rule. The result of setting this environment variable is the same as the combination of-mm,-MF, and-MT using command-line options. ==> also see sunpro_dependencies.

Gcc_exec_prefix If the environment variable is defined, it is prefixed with all subroutine names that the compiler executes. For example, if you set a variable to Testver instead of find as, the assembler first looks under the name Testveras. If it is not found here, the compiler will continue to look for its normal name. You can use a slash in the prefix name to indicate the path name.

The default setting for Gcc_exec_prefix is prefix/lib/gcc-lib/, where PREFIX is the name specified by the Configure script when the compiler is installed. The prefix is also used to locate standard connector files, which are included as part of the executable program. If you use the-B command-line option, this setting is overridden. ==> also see Compiler_path.

LANG This environment variable is used to indicate the character set used by the compiler to create wide-character text, string literals, and annotations. Defines LANG as C-jis, which indicates that the preprocessor interprets multibyte characters according to JIS (Japanese industry standard) characters. C-sjis can be used to indicate shift-jis characters and c-eucjp to indicate Japanese EUC. If LANG is not defined, or is defined as not recognized, the function Mblen () is used to determine the character width, and MBTOWC () is used to convert multibyte sequences to wide characters. Lc_all if set, the value of the environment variable overrides all settings of Lc_messages and Lc_ctype. LC_CTYPE the environment variable indicates the character classification of multibyte characters defined in the reference string. Primarily used to determine the character boundaries of a string, character encodings need to be quoted or escaped characters, which can be incorrectly interpreted as the end of a string or a special string. For Australian 中文版, you can set it to En_au, and to Mexican Spanish, you can set it to es_mx. If the variable is not set, the default is the value of the lang variable, or if Lang is not set, then the C English behavior is used. See also Lc_all. Lc_messages This environment variable indicates which language the compiler uses to emit diagnostic messages. For Australian 中文版, it can be set to En_au, and to Mexicanspanish, it can be set to ES_MX. If the variable is not set, the default value of the lang variable is used, or if Lang is not set, then the C English behavior is used. See also Lc_all. Ld_library_path This environment variable will not affect the compiler, but it will have an impact when the program runs. variable specifies a list of directories that the program will look for to locate the shared library. The executor must set the variable only if the shared library is not found in the directory of the compiled program. Ld_run_path This environment variable will not affect the compiler, but it will have an impact when the program runs. The variable indicates the name of the file at run time, and the running program can then get its symbolic name and address. The address is not re-loaded, so the symbol may refer to an absolute address in another file. This is exactly the same as the LD tool using the-r option.

Library_path the environment variable can be set to one or more directory name lists, the connector will search for the directory to find special connector files, and a library with the name specified by the-L (letter L) command-line option. The directory specified by the-l command-line option precedes the environment variable and is first looked up. ==> also see Compiler_path.

Objc_include_path Use this environment variable when compiling the OBJECTIVE-C program. The list of one or more directory names is specified by an environment variable, which is used to find the header file as if the-isystem option was specified on the command line. All directories specified by the-isystem option are first looked up. ==> also see CPath, Cplus_include_path and C_include_path.

Sunpro_output Setting this environment variable for the file name will cause the preprocessor to write to the file based on the makefile rule of the dependency. Will contain the system header file name. If the environment variable is set to a single name, it will be treated as a file name, and the name in the dependency rule will be obtained from the name of the source file. If there are two names in the definition, the second name is the target name in the dependency rule. The result of setting this environment variable is the same as using the parameters-M,-MF, and-MT on the command line. ==> See Dependencies_output.

TMPDIR This variable contains the pathname of the directory for the compiler to hold temporary working files. These files are usually deleted at the end of the compilation process. An example of such a file is a file that is output by the preprocessor and entered to the compiler.

Where is the Linux default include?

Which directory does the module.h default in #include <linux/module.h>? I didn't find the file under the/usr/include/linux.

Also want to ask, different kernel version of the Linux header file is not the same. For example: I am on the 2.6.20 kernel system, with 2.6.10 header file will not have the problem.

User reply:

1 My module.h is in the kernel compiled directory, not under the/usr/include/linux,

2 in the 2.6.20 kernel system, with the 2.6.10 header file should be a problem, the kernel header file and the current system running the kernel is inconsistent.

User reply: You are referring to the header file under the kernel. Not under the/usr/include. Under:/usr/src/kernels/2.6.18-8.el5-x86_64/include/linux/module.h ... The middle version number is not the same ... You can do it with your choice.

Netizen reply: Excuse me upstairs why is in/usr/src/kernels/2.6.18-8.el5-x86_64/include/linux/module.h? I checked the environment variable and didn't see the environment variable about the header file. How does GCC know the location of the header file?

User reply: This problem is very good, you need to look at the Linux kernel makefile file. Where to your change files, it's the final word. ：）

User reply: Your program is to drive the kernel layer of the kind, right?

The header file it calls should be the include in the kernel source code. The general system of the kernel source is placed under the/USR/SRC, if it is compiled by their own kernel, can also be placed elsewhere. As to where GCC goes to your change files, see Makefile, or directly with the GCC command, add-I to specify the directory.

Netizen reply: Upstairs, but my makefile didn't specify include yes, how did GCC find the header file?

User reply: How does gcc find the header file?

================================

Answer this question, LZ will understand everything,gcc your change file has three kinds of strategies :

1. will be specified by default to the/usr/include folder ( deeper is a relative path, the path of the GCC executable is/usr/bin, then it is actually working when the header file header diameter is a relative path method, converted to absolute path is/usr /include)

2.GCC also uses the-I method to specify the path , which we all know

3. You can also use a parameter to indicate that GCC does not search the system default path , this parameter I forgot, you'll find out if you search.

When compiling the driver module, due to the extraordinary demand must force GCC does not search the system default path, that is, do not search/usr/include, to use the-I parameter to specify the kernel header file path, this time must be specified in the makefile two parameters, one is the kernel header file path, One is to force GCC to not search the system default path. When compiling the kernel, you must use one parameter (forcing GCC to not search the system default path), or it will cause confusion.

Understand the above principle, LZ himself should be able to find the answer????

From: http://www.itzhe.cn/news/20071216/31985.html

Linux Specifies dynamic library paths

As we all know, the default search path for Linux dynamic libraries is/lib and/usr/lib and Usr/local/lib. When a dynamic library is created, it is generally copied to both directories. When the program executes requires a dynamic library, and the dynamic library is not loaded into memory, the system will automatically go to the two default search paths to find the corresponding dynamic library file, and then load the file into memory, so that the program can use the function in the dynamic library, as well as other resources of the dynamic library.

In Linux, the search path for a dynamic library can be specified in the following three ways, in addition to the default search path.

Method One: Specify the Dynamic library search path in the configuration file/etc/ld.so.conf .

You can specify a search path for a dynamic library by editing the configuration file/etc/ld.so.conf, where each row is a dynamic library search path. Each time you finish editing the file, you must run the command ldconfig for the modified configuration to take effect. We illustrate the method by example.

Example 1: We use the following command to create a dynamic library libpos.so with the source program POS_CONF.C (see Program 1), the detailed creation process is referred to in the article [1].

# gcc-c POS_CONF.C

# Gcc-shared-fpci-o libpos.so POS_CONF.O

#include <stdio.h>

void Pos ()

{printf ("/root/test/conf/lib/n");}

Program 1:POS_CONF.C

Then compile the MAIN.C (see Program 2) to generate the target program POS with the following command.

# gcc-o Pos main.c-l.-lpos #

void Pos ();

int main ()

{pos (); return 0;}

Program 2:MAIN.C

Then move the library file to the directory/root/test/conf/lib.

# mkdir-p/root/test/conf/lib

# MV Libpos.so/root/test/conf/lib

# Finally, edit the configuration file/etc/ld.so.conf and append a line "/root/test/conf/lib" to the file.

Try running the program POS.

#./pos./pos:error while loading shared libraries:libpos.so:cannot open Shared object file:no such file or directory

# error, the system did not find the dynamic library libpos.so. Look for reasons, the original after editing the configuration file/etc/ld.so.conf, did not run the command ldconfig, so just the changes have not yet taken effect. We run Ldconfig and try again.

# Ldconfig

#./pos/root/test/conf/lib

# The program POS runs successfully and prints the correct results.

Method Two: Specify the Dynamic library search path through the environment variable Ld_library_path .

You can also specify a dynamic library search path by setting the environment variable Ld_library_path. When multiple dynamic library search paths are specified through the environment variable, the paths are separated by a colon ":".

This method is illustrated by the following example.

Example 2:

We use the following command to create a dynamic library libpos.so with the source program POS_ENV.C (see program 3).

# gcc-c POS_ENV.C

# Gcc-shared-fpci-o libpos.so POS_ENV.O

#

#include <stdio.h>

void Pos ()

{printf ("/root/test/env/lib/n");}

Program 3:POS_ENV.C

The test executable POS can be used in example 1 to get the target program POS, which does not need to be compiled again. Because the function pos in POS_CONF.C and the function pos function in POS_ENV.C are identical, and the dynamic library name is the same, it is like recreating the library after modifying the dynamic library pos. This is also one of the advantages of using dynamic libraries.

Then move the dynamic library libpos.so to the directory/root/test/conf/lib.

# mkdir-p/root/test/env/lib

# MV Libpos.so/root/test/env/lib

# we can use export to set the environment variable, which is valid for all commands after setting the environment variable.

For example:

# Export Ld_library_path=/root/test/env/lib

# But for the sake of convenience, another way to set the environment variable is to set the environment variable before the command, which is only valid for the command, and the environment variable is invalid when the command executes. As the following command:

# Ld_library_path=/root/test/env/lib./pos/root/test/env/lib

# The program POS runs successfully, and the result of printing is "/root/test/env/lib", which is the result of the function POS running in program POS_ENV.C. So the dynamic library that the program POS searches for is/root/test/env/lib/libpos.so.

method Three: Specify the dynamic library search path for the program when compiling the target code .

You can also specify the dynamic library search path for the program when compiling the target code. -WL, indicating that subsequent arguments will be passed to the link program LD (since GCC may automatically invoke LD). Here is the parameter "-wl,-rpath," specified by GCC (as shown in Example 3). When you specify multiple dynamic library search paths, the paths are separated by a colon ":".

Example 3: We use the following command to create a dynamic library libpos.so with the source program POS.C (see program 4).

# gcc-c POS.C

# Gcc-shared-fpci-o libpos.so POS.O

#

#include <stdio.h>

void Pos ()

{printf (".//n");}

Program 4:POS.C

Because we need to specify the dynamic library search path of the executable when compiling the target code, we need to recompile the source program MAIN.C (see Program 2) with the GCC command to generate the executable pos.

# gcc-o POS main.c-l.-lpos-wl,-rpath,./

# Try running the program POS again.

#./pos

./# The program POS runs successfully, and the output is the result of the function pos running in POS.C. So the dynamic library that the program POS searches for IS./libpos.so.

Example

Gcc-wl,-rpath,/home/arc/test,-rpath,/lib/,-rpath,/usr/lib/,-rpath,/usr/local/lib test.c

The above describes three ways to specify the dynamic library search path, plus the default dynamic library search path/lib and/usr/lib, a total of five dynamic library search paths, then what is the order of their search?

In the introduction of the three methods described above, a dynamic library was created./libpos.so,/root/test/env/lib/libpos.so and/root/test/conf/lib/libpos.so.

We then use the source program POS_LIB.C (see program 5) to create the dynamic library/lib/libpos.so, using the source program POS_USRLIB.C (see program 6) to create a dynamic library/usr/lib/libpos.so.

#include <stdio.h> void Pos () {printf ("/lib/n");} program 5:POS_LIB.C

#include <stdio.h> void Pos () {printf ("/usr/lib/n");} program 6:POS_USRLIB.C

So we get five dynamic library libpos.so, these dynamic libraries have the same name, and all contain common function pos of the same function prototype. But the location of the store differs from the result of the common function pos printing. The common function pos in each dynamic library outputs the location where the dynamic library is stored. In this way, we can find out which dynamic library it searched for by executing the results from the executable pos in Example 3, get the 1th Dynamic Library search order, then delete the dynamic library, execute the program POS, get the 2nd Dynamic Library search path, and delete the 2nd search dynamic library, so reciprocating, The sequencing of the Linux search dynamic Library will be available. The corresponding relationship between the output of the program POS execution and the search for the dynamic library is shown in table 1:

The program POS output results use a dynamic library that corresponds to the dynamic library search path specified in the method././libpos.so The Dynamic library search path specified when compiling the target code/root/test/env/lib/root/test/env/lib/libpos.so Environment variable Ld_library_path Specifies the dynamic library search path/root/test/conf/lib/root/test/conf/lib/libpos.so the dynamic library search path specified in the configuration file/etc/ld.so.conf/ Lib/lib/libpos.so The default dynamic library search path/lib/usr/lib/usr/lib/libpos.so the default dynamic library search path/usr/lib

Table 1: Correspondence between program POS output and dynamic libraries

Create individual dynamic libraries and place them in the appropriate directory. The test environment is ready. Execute the program POS and set the environment variable Ld_library_path in the command line.

# ld_library_path=/root/test/env/lib./pos./#

According to the output results of the program POS, the first search is the dynamic library search path specified when compiling the target code. Then we remove the dynamic library./libpos.so, and then run the above command to try again.

# RM libpos.so rm:remove regular file ' libpos.so '? Y # ld_library_path=/root/test/env/lib./pos/root/test/env/lib #

According to the output results of the program POS, the 2nd Dynamic Library search path is specified by the environment variable Ld_library_path. We'll remove the/root/test/env/lib/libpos.so and run the above command.

# rm/root/test/env/lib/libpos.so rm:remove regular file '/root/test/env/lib/libpos.so '? Y # ld_library_path=/root/test/env/lib./pos/root/test/conf/lib #

The search path for the 3rd dynamic library is the path specified by the configuration file/etc/ld.so.conf. Remove the/root/test/conf/lib/libpos.so and run the above command.

# rm/root/test/conf/lib/libpos.so rm:remove regular file '/root/test/conf/lib/libpos.so '? Y # ld_library_path=/root/test/env/lib./pos/lib #

The search path for the 4th dynamic Library is the default search path,/lib. We then delete the dynamic library/lib/libpos.so and run the above command.

# rm/lib/libpos.so rm:remove regular file '/lib/libpos.so '? Y

# ld_library_path=/root/test/env/lib./pos/usr/lib #

The last dynamic library search path is the default search path,/usr/lib.

combined with the above results, The order of search path search for dynamic libraries is:

1. The dynamic library search path specified when compiling the target code;

2. Environment variable LD_LIBRARY_PATH the specified dynamic library search path;

3. The dynamic library search path specified in the configuration file/etc/ld.so.conf;

4. The default dynamic library search path/lib;

5. The default dynamic library search path/usr/lib.

When you specify a dynamic library search path in the above 1, 2, 3, you can specify multiple dynamic library search paths, which are searched in the order of the specified paths. For this article no longer an example, interested readers can refer to the method of this article to verify.

Source: http://hi.baidu.com/kkernel/blog/item/ce31bb34a07e6b46251f14cf.html

The following article is a summary of the previous article

Linux operating system header file and library file search path

Include header files, dynamic link libraries, system definitions, and a total of the following sources specify GCC to go there.

Originally specified at compile time (in ~gcc/gcc/collect2.c:locatelib ()

Written in the specs, the default, this is the original compile GCC when written in the program.

Later with-d-i-L specified

GCC environment variable setting (when compiling)

ld.so Environment variables (this is run time)

First, the header file how does gcc look for the required header files at compile time:

※ The search for header file will start with-I

/usr/include※ then look for the GCC environment variable C_include_path,cplus_include_path,objc_include_path

※ Find the default catalogue again

/usr/local/include

/usr/lib/gcc-lib/i386-linux/2.95.2/include

/usr/lib/gcc-lib/i386-linux/2.95.2/. /.. /.. /.. /include/g++-3

/usr/lib/gcc-lib/i386-linux/2.95.2/. /.. /.. /.. /i386-linux/include

Library file, but if you have a given prefix when you install GCC, it is

/usr/include

Prefix/include

Prefix/xxx-xxx-xxx-gnulibc/include

Prefix/lib/gcc-lib/xxxx-xxx-xxx-gnulibc/2.8.1/include

Second, the library file

The options for the Cos () function library are more-LM

Compile the time:

※GCC will find-L.

※ re-search for GCC environment variable Library_path

※ Find the default directory/lib/usr/lib/usr/local/lib This is the original compile GCC written in the program

Third, run-time dynamic Library search Path

1. Specify the dynamic library search path in the configuration file/etc/ld.so.conf

2. Specify the dynamic library search path through the environment variable Ld_library_path (when multiple dynamic library search paths are specified through the environment variable, the paths are separated by a colon ":")

3. Specify the dynamic library search path for the program when compiling the target code (you can also specify the program's dynamic Library search path when compiling the target code). This is specified through the GCC parameter "-wl,-rpath," as shown in Example 3. When multiple dynamic library search paths are specified, the paths are separated by a colon ":"

4, the default dynamic library search path/lib

5, the default dynamic library search path/usr/lib

You can find out which dynamic library to search for by executing the results from the executable pos, get the 1th Dynamic Library search order, and then delete the dynamic library.

Then execute the program POS, get the 2nd Dynamic Library search Path,

And then delete the 2nd dynamic library that was searched,

In this way, you will get the sequencing of the Linux search dynamic library.

The corresponding relationship between the output of the program POS execution and the search dynamic library is shown in table 1

Dynamic Library search path specified by the dynamic library corresponding to the program POS output results

././libpos.so The Dynamic library search path specified when compiling the target code

/root/test/env/lib/root/test/env/lib/libpos.so environment variable Ld_library_path the specified dynamic library search path/root/test/conf/lib/root/test/conf/ Lib/libpos.so The dynamic library search path specified in configuration file/etc/ld.so.conf

/lib/lib/libpos.so The default dynamic library search path/lib

/usr/lib/usr/lib/libpos.so The default dynamic library search path/usr/lib

Combined with the above results, the order of search path search for dynamic library is as follows:

1. The dynamic library search path specified when compiling the target code;

2. Environment variable LD_LIBRARY_PATH the specified dynamic library search path;

3. The dynamic library search path specified in the configuration file/etc/ld.so.conf;

4. The default dynamic library search path/lib;

5. Default dynamic Library search path/usr/lib

Organize the problems related to the search path of header files and library files in the GCC compilation of Linux