Environment variables, include search path, LIB Library search path

Environment variables

System Environment variables

We know that we often have to set some environment variables, system environment variables we are very easy to understand. In fact, we are often easy to contact in Windows. In fact, environment variables are a very broad concept that is similar to the role of Web. config in an application. What do you mean? That is, when a program (System or application) is to run, its basic business logic may be certain, but when it comes to implementing the business logic, some of the setup things can change the program a lot. such as a Web application, after compiling his business logic basically does not change, but if you change some of the parameters in Web. config, the operation of the program will change accordingly. These settings. Just like the TV on the top of the modulation. Changing the settings will get some difference.

So environment variables can be understood as one of the settings, why is it not directly called setting it? Because it's in a passive position. The more said the more confused.

The most common environment variables are path, and classpath, which needs to be set when setting up the JDK, where the path variable refers to when the system's interface receives a program start command, in addition to the default in the current directory to find the executable file unexpectedly, but also need to find those places. With this setting, you don't have to go into that directory to execute that program. The CLASSPATH variable is similar, it sets the path that resembles the dynamic library, that is, when the program executes, it discovers to introduce the dynamic library, so we should find it in the place where this variable is specified.

In Linux, the system also has a path variable. In fact, the system has a file that specifically records those environment variables.

1) etcprofile, the system login will execute this file to introduce those variables in the current environment.

2) also homeali.bashrc this file, simply put, etcprofile is effective for the global, and. BASHRC is valid for the current user.

3) There is also a setup method, which is directly modified by the terminal command, we know that the first two files the way it works is when the program enters the state, they will be executed into the current space, then in the current state will have these variables, the program is to use them. Then if we modify them directly in memory, we can play a temporary role.

Program Environment variables

According to the previous we said the role of environmental variables and significance, it is easy to launch, ordinary programs can also have environment variables. A pattern that works according to the environment variables of the previous system. Application, you can also have some configuration files to persist these environment variables, when the program executes, these variables will be in some way into the program execution space, so that the program can use these variables when executing. And again, we can change these variables to "moderate" change our program.

GCC is such a program. Most of the time, the application needs no environment variable mechanism, the key to see if he has a lot of selectivity, GCC is a program like this.

The most common GCC environment variables are the include search path and the library search path. They are used when compiling and connecting.

The background of their use is:

Include Search path

Usually, when using cc++ to develop the program, will use the header file, and there is a header file implementation file, this time there are three types of files, using the header file source files, header files, implementation of the header file source files. When compiling, the header file and the source file are all together. Usually they are in the same directory. So there's no problem.

However, when you use some of the system's own header files, you need to introduce some header files, and these files are not in the current directory, the use of absolute address is a method, but is a very bad way. So GCC has a search mechanism. is to search for the header file you have introduced under the specified folders. This solves the problem. This environment variable is called Cplus_include_path. belongs to GCC and is system independent. Let's look at the GCC header file search path

Header file:

1. #include "headfile.h"

The search order is:

① Search the current directory first

② then searches for the directory specified by-I.

③ re-search for GCC environment variables Cplus_include_path (c program uses C_include_path)

④ final search for the default directory for GCC

Usrinclude

Usrlocalinclude

Usrlibgccx86_64-redhat-linux4.1.1include

When the same file exists for each directory, it is first found which one to use.

2. #include headfile.h

① first search for the directory specified by-I.

② then search for GCC environment variables Cplus_include_path

③ final search for the default directory for GCC

Usrinclude

Usrlocalinclude

Usrlibgccx86_64-redhat-linux4.1.1include

The same as above, when the same files exist in each directory, first find which one to use. Notice here, #include方式不会搜索当前目录!

Although the search for the GCC custom environment variable directory, the next default directory, it should be the operating system of the definition of such a header file. This deduction is correct. In fact, that's not true. The GCC header file search mode, also in accordance with the first "special" after the "wide" mode, that is, most of them are using their own set, so basic can be found, there may be some are those who share the header files. So, the default directory here is actually not much different from the meaning of the directory that inherits the operating system.

Here to say include the default directory, it is not specified by the $PATH environment variable, but is specified by the configuration of g++ prefix (know that it can be specified in the installation of g++, do not know how to modify after installation, may be modified configuration file, need to study again):

-bash-3.2$ g++-V

Using built-in specs.

Target X86_64-redhat-linux

Configured with. Configure--PREFIX=USR--mandir=usrshareman--infodir=usrshareinfo--enable-shared--enable-threads=posix-- Enable-checking=release--with-system-zlib--enable-__cxa_atexit--disable-libunwind-exceptions-- Enable-libgcj-multifile--enable-languages=c,c++,objc,obj-c++,java,fortran,ada--ENABLE-JAVA-AWT=GTK-- Disable-dssi--enable-plugin--with-java-home=usrlibjvmjava-1.4.2-gcj-1.4.2.0jre--with-cpu=generic--host=x86_64- Redhat-linux

Thread model POSIX

GCC version 4.1.2 20080704 (Red Hat 4.1.2-46)

When installing g++, prefix is specified, then the default search directory is:

Prefixinclude

Prefixlocalinclude

Prefixlibgcc--host--versioninclude

The default directory search header file can be masked by the-nostdinc++ option at compile time.

Library Search Path:

After compiling, the program to link operations, the previous point out that the link is dynamic and static, GCC this program, it must be confirmed that the "really have" the implementation of those header files. So we need to locate the files. Similar to the scenario for include. Using an absolute directory is possible, but not suitable for administration. Then there is the environment variable of the LIB search path. Library_path.

Their search paths are:

Library files:

Compile the time:

①GCC will find-L.

② the environment variables for GCC Library_path

③ again find the default directory Lib Usrlib usrlocallib This is the original compile GCC written in the program (not configurable? ）

Search paths for runtime dynamic libraries

(Do not confuse this with the search path of the library, where the program executes when the Linux system USRBINLD program control process, here is just incidentally introduced.) The whole life cycle of the entire program. Compile, link, start, load (including dynamic loading), execute):

The order of search path search for dynamic libraries is:

① The dynamic library search path specified when compiling the target code (this is specified by the GCC parameter,-wl,-rpath. When multiple dynamic library search paths are specified, the paths are separated by colons:

② environment variable Ld_library_path the specified dynamic library search path (when multiple dynamic library search paths are specified through the environment variable, the paths are separated by colons: delimited)

③ The dynamic library search path specified in the configuration file etcld.so.conf;

④ The default dynamic library search path lib;

⑤ The default dynamic library search path Usrlib.

We are here to summarize this aspect of the GCC command.

Compile with the-I command to load the include search path.

When connecting, use the-l-l command to mount a connection search path or file

The time of execution. Use-WL, the search path that can be loaded into the dynamic library when the connection was compiled.

Environment variables, include search path, LIB Library search path