OneCoder在學習C++的過程中，在研究Windows下Eclipse for C/C++開發環境的過程中遇到的一些關於C++環境變數的一些問題。在網上搜索一番，得到下面的文章，與大家分享。
轉自：http://blog.sina.com.cn/s/blog_93b45b0f01011nrz.html

環境變數

系統環境變數

我們知道，我們經常要設定一些環境變數，系統環境變數我們非常容易理解。其實我們在windows中經常容易接觸。其實環境變數是一個非常廣泛的一個概念，它與web應用程式中的web.config所處的角色很像。什麼意思呢？就是說，程式（系統或應用）要執行的時候，它的基本業務邏輯可能是一定的，但是實現業務邏輯的時候有些設定性的東西卻可以改變程式很多。如web應用程式，編譯之後他的業務邏輯基本不會發生改變，但是如果你更改一些web.config中的引數，程式的執行就會發生相應的改變。這些設定。就像電視機上面調製一樣。改變了設定會得到某些不同。
那麼環境變數可以理解成設定的一種，為什麼有不直接稱為設定呢？因為它處於一種被動的境地。越多說越糊塗。
最常見的環境變數莫過於PATH，和ClassPATH，這個在設定jdk的時候就需要設定，這裡的PATH變數指的是，當系統的介面接收到一個程式啟動命令的時候，除了預設在當前目錄下尋找那個可執行檔案意外，還需要到那些地方尋找。有了這個設定，你就不需要一定要進入那個目錄才能執行那個程式了。ClassPATH變數也差不多，它設定的是那些類似於動態庫的路徑，也就是說，程式在執行的時候，發現要引入動態庫，那樣就要在這個變數指定的地方去找。
在linux中，系統也有一個PATH變數。其實系統有一個檔案是專門記錄那些環境變數的。
1）/etc/profile，系統登入會執行這個檔案在當前環境中引入那些變數。
2）還有  /home/ali/.bashrc 這個檔案，簡單的來說，/etc/profile是對全域性有效的，而./bashrc是對當前使用者有效.
3）還有一種設定方法，就是通過終端命令直接修改，我們知道前面兩個檔案其作用的方式就是當程式進入狀態的時候，他們會被執行引入到當前空間，那麼在當前狀態下就會有這些變數，程式也就是可以使用它們。那麼如果我們直接在記憶體中修改該他們，就可以起到暫時的作用。

程式環境變數

根據前面我們說過環境變數的作用和意義，就很容易推出，普通的程式也可以有環境變數。按照前面系統的環境變數起作用的模式。應用程式，也可以有一些配置檔案來持久儲存這些環境變數，在程式執行的時候，這些變數會通過某種方式進入程式執行的空間，這樣程式執行的時候就可以使用這些變量了。而同樣，我們可以改變這些變數來“適量”的改變我們的程式。
GCC就是這樣一個程式。很多時候，應用程式需不需要環境變數機制，關鍵看他是否有很多的選擇性，GCC就是一個這樣的程式。
最常用GCC環境變數的就是include搜尋路徑，以及庫搜尋路徑。他們分別在編譯和連線的時候使用。
他們的使用背景是：

include搜尋路徑

通常，使用C/C++進行開發程式的時候，會使用標頭檔案，並且有標頭檔案的實現檔案，這個時候有三類檔案，使用標頭檔案的原始檔，標頭檔案，實現標頭檔案的原始檔。編譯的時候，標頭檔案和原始檔一起就可以了。通常他們是在同一目錄下的。所以不會有什麼問題。
但是，當你使用到了系統自身的一些標頭檔案的時候，你需要引入一些標頭檔案，而這些檔案不在當前目錄下，使用絕對地址是一個辦法，但是是一個極差的辦法。所以GCC就有一個搜尋機制。就是在規定的那些資料夾下，搜尋你所引入的那個標頭檔案。這樣解決了問題。這個環境變數叫著CPLUS_INCLUDE_PATH。屬於GCC，與系統無關。我們看看GCC標頭檔案搜尋路徑

標頭檔案：
1.#include “headfile.h”
搜尋順序為：
①先搜尋當前目錄
②然後搜尋-I指定的目錄
③再搜尋gcc的環境變數CPLUS_INCLUDE_PATH（C程式使用的是C_INCLUDE_PATH）
④最後搜尋gcc的內定目錄

/usr/include
/usr/local/include
/usr/lib/gcc/x86_64-redhat-linux/4.1.1/include

各目錄存在相同檔案時，先找到哪個使用哪個。
2.       #include <headfile.h>
①先搜尋-I指定的目錄
②然後搜尋gcc的環境變數CPLUS_INCLUDE_PATH
③最後搜尋gcc的內定目錄

/usr/include
/usr/local/include
/usr/lib/gcc/x86_64-redhat-linux/4.1.1/include

與上面的相同，各目錄存在相同檔案時，先找到哪個使用哪個。這裡要注意，#include<>方式不會搜尋當前目錄！

雖然搜尋了GCC自定義的環境變數目錄之後，下一個的內定目錄，就應該是作業系統有關這種標頭檔案的定義。這種推導很正確。事實上就算不是這樣的。GCC標頭檔案搜尋模式，也是按照先“專”後“寬”的模式，也就是說，大部分都是使用自己的一套，所以基本都能找到，可能真有一些是那些大家共有的標頭檔案。所以，這裡的內定目錄其實與繼承作業系統的目錄的意思沒有多大區別。

這裡要說下include的內定目錄，它不是由$PATH環境變數指定的，而是由g++的配置prefix指定的(知道它在安裝g++時可以指定，不知安裝後如何修改的，可能是修改配置檔案，需要時再研究下)：

-bash-3.2$ g++ -v
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --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=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)

在安裝g++時，指定了prefix，那麼內定搜尋目錄就是：

Prefix/include
Prefix/local/include
Prefix/lib/gcc/--host/--version/include

編譯時可以通過-nostdinc++選項遮蔽對內定目錄搜尋標頭檔案。


庫搜尋路徑：

在編譯之後，程式要進行連結操作，前面指出，連結不管是動態和是靜態，GCC這個程式，必須確認“真的有”那些標頭檔案的實現。於是就需要定位找到那些檔案。與include的情景差不多。使用絕對目錄是可以的，但不適於管理。於是就出現了lib搜尋路徑這個環境變數。LIBRARY_PATH。
他們的搜尋路徑為：
庫檔案：
編譯的時候：
①gcc會去找-L
②再找gcc的環境變數LIBRARY_PATH
③再找內定目錄 /lib /usr/lib /usr/local/lib 這是當初compile gcc時寫在程式內的（不可配置的？）

執行時動態庫的搜尋路徑
(不要把這個和庫的搜尋路徑混淆了，這裡程式執行的時候有linux系統/usr/bin/ld程式控制的過程，這裡只是順帶介紹。以完整程式整個生命週期。編譯、連結、啟動，裝載（包括動態裝載)、執行）：
動態庫的搜尋路徑搜尋的先後順序是：
①編譯目的碼時指定的動態庫搜尋路徑（這是通過gcc 的引數"-Wl,-rpath,"指定。當指定多個動態庫搜尋路徑時，路徑之間用冒號"："分隔）
②環境變數LD_LIBRARY_PATH指定的動態庫搜尋路徑（當通過該環境變數指定多個動態庫搜尋路徑時，路徑之間用冒號"："分隔）
③配置檔案/etc/ld.so.conf中指定的動態庫搜尋路徑；
④預設的動態庫搜尋路徑/lib；
⑤預設的動態庫搜尋路徑/usr/lib。

我們在來對GCC這個命令的這一方面進行總結一下。
編譯的時候使用-I命令可以裝入include搜尋路徑。
連線的時候使用-l  -L命令可以裝入連線搜尋路徑或檔案
執行的時候。在當初編譯連線時候使用-Wl 這個可以裝入動態庫的搜尋路徑。