一、編譯和連接
一般來說，如果庫的頭文件不在 /usr/include 目錄中，那麼在編譯的時候需要用 -I 參數指定其路徑。由於同一個庫在不同系統上可能位於不同的目錄下，用戶安裝庫的時候也可以將庫安裝在不同的目錄下，所以即使使用同一個庫，由於庫的路徑的不同，造成了用 -I 參數指定的頭文件的路徑也可能不同，其結果就是造成了編譯命令界面的不統一。如果使用 -L 參數，也會造成連接界面的不統一。編譯和連接界面不統一會爲庫的使用帶來麻煩。
爲了解決編譯和連接界面不統一的問題，人們找到了一些解決辦法。其基本思想就是：事先把庫的位置信息等保存起來，需要的時候再通過特定的工具將其中有用的信息提取出來供編譯和連接使用。這樣，就可以做到編譯和連接界面的一致性。其中，目前最爲常用的庫信息提取工具就是下面介紹的 pkg-config。
pkg-config 是通過庫提供的一個 .pc 文件獲得庫的各種必要信息的，包括版本信息、編譯和連接需要的參數等。這些信息可以通過 pkg-config 提供的參數單獨提取出來直接供編譯器和連接器使用。
The pkgconfig package contains tools for passing the include path and/or library paths to build tools during the make file execution.
pkg-config is a function that returns meta information for the specified library.
The default setting for PKG_CONFIG_PATH is /usr/lib/pkgconfig because of the prefix we use to install pkgconfig. You may add to PKG_CONFIG_PATH by exporting additional paths on your system where pkgconfig files are installed. Note that PKG_CONFIG_PATH is only needed when compiling packages, not during run-time.
在默認情況下，每個支持 pkg-config 的庫對應的 .pc 文件在安裝後都位於安裝目錄中的 lib/pkgconfig 目錄下。例如，我們在上面已經將 Glib 安裝在 /opt/gtk 目錄下了，那麼這個 Glib 庫對應的 .pc 文件是 /opt/gtk/lib/pkgconfig 目錄下一個叫 glib-2.0.pc 的文件：
prefix=/opt/gtk/
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
glib_genmarshal=glib-genmarshal
gobject_query=gobject-query
glib_mkenums=glib-mkenums
Name: GLib
Description: C Utility Library
Version: 2.12.13
Libs: -L${libdir} -lglib-2.0
Cflags: -I${includedir}/glib-2.0 -I${libdir}/glib-2.0/include
使用 pkg-config 的 --cflags 參數可以給出在編譯時所需要的選項，而 --libs 參數可以給出連接時的選項。例如，假設一個 sample.c 的程序用到了 Glib 庫，就可以這樣編譯：
$ gcc -c `pkg-config --cflags glib-2.0` sample.c
然後這樣連接：
$ gcc sample.o -o sample `pkg-config --libs glib-2.0`
或者上面兩步也可以合併爲以下一步：
$ gcc sample.c -o sample `pkg-config --cflags --libs glib-2.0`
可以看到：由於使用了 pkg-config 工具來獲得庫的選項，所以不論庫安裝在什麼目錄下，都可以使用相同的編譯和連接命令，帶來了編譯和連接界面的統一。
使用 pkg-config 工具提取庫的編譯和連接參數有兩個基本的前提：
1.庫本身在安裝的時候必須提供一個相應的 .pc 文件。不這樣做的庫說明不支持 pkg-config 工具的使用。
2.pkg-config 必須知道要到哪裏去尋找此 .pc 文件。
GTK+ 及其依賴庫支持使用 pkg-config 工具，所以剩下的問題就是如何告訴 pkg-config 到哪裏去尋找庫對應的 .pc 文件，這也是通過設置搜索路徑來解決的。
對於支持 pkg-config 工具的 GTK+ 及其依賴庫來說，庫的頭文件的搜索路徑的設置變成了對 .pc 文件搜索路徑的設置。.pc 文件的搜索路徑是通過環境變量 PKG_CONFIG_PATH 來設置的，pkg-config 將按照設置路徑的先後順序進行搜索，直到找到指定的 .pc 文件爲止。
安裝完 Glib 後，在 bash 中應該進行如下設置：
$ export PKG_CONFIG_PATH=/opt/gtk/lib/pkgconfig:$PKG_CONFIG_PATH
可以執行下面的命令檢查是否 /opt/gtk/lib/pkgconfig 路徑已經設置在 PKG_CONFIG_PATH 環境變量中：
$ echo $PKG_CONFIG_PATH
這樣設置之後，使用 Glib 庫的其它程序或庫在編譯的時候 pkg-config 就知道首先要到 /opt/gtk/lib/pkgconfig 這個目錄中去尋找 glib-2.0.pc 了（GTK+ 和其它的依賴庫的 .pc 文件也將拷貝到這裏，也會首先到這裏搜索它們對應的 .pc 文件）。之後，通過 pkg-config 就可以把其中庫的編譯和連接參數提取出來供程序在編譯和連接時使用。
另外還需要注意的是：環境變量的設置只對當前的終端窗口有效。如果到了沒有進行上述設置的終端窗口中，pkg-config 將找不到新安裝的 glib-2.0.pc 文件、從而可能使後面進行的安裝（如 Glib 之後的 Atk 的安裝）無法進行。
在我們採用的安裝方案中，由於是使用環境變量對 GTK+ 及其依賴庫進行的設置，所以當系統重新啓動、或者新開一個終端窗口之後，如果想使用新安裝的 GTK+ 庫，需要如上面那樣重新設置 PKG_CONFIG_PATH 和 LD_LIBRARY_PATH 環境變量。
這種使用 GTK+ 的方法，在使用之前多了一個對庫進行設置的過程。雖然顯得稍微繁瑣了一些，但卻是一種最安全的使用 GTK+ 庫的方式，不會對系統上已經存在的使用了 GTK+ 庫的程序（比如 GNOME 桌面）帶來任何衝擊。
爲了使庫的設置變得簡單一些，可以把下面的這兩句設置保存到一個文件中（比如 set_gtk-2.10 文件）:
export PKG_CONFIG_PATH=/opt/gtk/lib/pkgconfig:$PKG_CONFIG_PATH
export LD_LIBRARY_PATH=/opt/gtk/lib:$LD_LIBRARY_PATH
之後，就可以用下面的方法進行庫的設置了（其中的 source 命令也可以用 . 代替）：
$ source set_gtk-2.10
只有在用新版的 GTK+ 庫開發應用程序、或者運行使用了新版 GTK+ 庫的程序的時候，纔有必要進行上述設置。
如果想避免使用 GTK+ 庫之前上述設置的麻煩，可以把上面兩個環境變量的設置在系統的配置文件中（如 /etc/profile）或者自己的用戶配置文件中（如 ~/.bash_profile） ；庫的搜索路徑也可以設置在 /etc/ld.so.conf 文件中，等等。這種設置在系統啓動時會生效，從而會導致使用 GTK+ 的程序使用新版的 GTK+ 運行庫，這有可能會帶來一些問題。當然，如果你發現用新版的 GTK+ 代替舊版沒有什麼問題的話，使用這種設置方式是比較方便的。加入到~/.bashrc中，例如：
PKG_CONFIG_PATH=/opt/gtk/lib/pkgconfig
重啓之後：
[root@localhost ~]# echo $PKG_CONFIG_PATH
/opt/gtk/lib/pkgconfig
二、運行時
庫文件在連接（靜態庫和共享庫）和運行（僅限於使用共享庫的程序）時被使用，其搜索路徑是在系統中進行設置的。一般 Linux 系統把 /lib 和 /usr/lib 兩個目錄作爲默認的庫搜索路徑，所以使用這兩個目錄中的庫時不需要進行設置搜索路徑即可直接使用。對於處於默認庫搜索路徑之外的庫，需要將庫的位置添加到庫的搜索路徑之中。設置庫文件的搜索路徑有下列兩種方式，可任選其一使用：
1.在環境變量 LD_LIBRARY_PATH 中指明庫的搜索路徑。
2.在 /etc/ld.so.conf 文件中添加庫的搜索路徑。
將自己可能存放庫文件的路徑都加入到/etc/ld.so.conf中是明智的選擇 ^_^
添加方法也極其簡單，將庫文件的絕對路徑直接寫進去就OK了，一行一個。例如：
/usr/X11R6/lib
/usr/local/lib
/opt/lib
需要注意的是：第二種搜索路徑的設置方式對於程序連接時的庫（包括共享庫和靜態庫）的定位已經足夠了，但是對於使用了共享庫的程序的執行還是不夠的。這是因爲爲了加快程序執行時對共享庫的定位速度，避免使用搜索路徑查找共享庫的低效率，所以是直接讀取庫列表文件 /etc/ld.so.cache 從中進行搜索的。/etc/ld.so.cache 是一個非文本的數據文件，不能直接編輯，它是根據 /etc/ld.so.conf 中設置的搜索路徑由 /sbin/ldconfig 命令將這些搜索路徑下的共享庫文件集中在一起而生成的（ldconfig 命令要以 root 權限執行）。因此，爲了保證程序執行時對庫的定位，在 /etc/ld.so.conf 中進行了庫搜索路徑的設置之後，還必須要運行 /sbin/ldconfig 命令更新 /etc/ld.so.cache 文件之後纔可以。ldconfig ,簡單的說，它的作用就是將/etc/ld.so.conf列出的路徑下的庫文件 緩存到/etc/ld.so.cache 以供使用。因此當安裝完一些庫文件，(例如剛安裝好glib)，或者修改ld.so.conf增加新的庫路徑後，需要運行一下 /sbin/ldconfig使所有的庫文件都被緩存到ld.so.cache中，如果沒做，即使庫文件明明就在/usr/lib下的，也是不會被使用的，結果編譯過程中抱錯，缺少xxx庫，去查看發現明明就在那放着，搞的想大罵computer蠢豬一個。 ^_^
在程序連接時，對於庫文件（靜態庫和共享庫）的搜索路徑，除了上面的設置方式之外，還可以通過 -L 參數顯式指定。因爲用 -L 設置的路徑將被優先搜索，所以在連接的時候通常都會以這種方式直接指定要連接的庫的路徑。
前面已經說明過了，庫搜索路徑的設置有兩種方式：在環境變量 LD_LIBRARY_PATH 中設置以及在 /etc/ld.so.conf 文件中設置。其中，第二種設置方式需要 root 權限，以改變 /etc/ld.so.conf 文件並執行 /sbin/ldconfig 命令。而且，當系統重新啓動後，所有的基於 GTK2 的程序在運行時都將使用新安裝的 GTK+ 庫。不幸的是，由於 GTK+ 版本的改變，這有時會給應用程序帶來兼容性的問題，造成某些程序運行不正常。爲了避免出現上面的這些情況，在 GTK+ 及其依賴庫的安裝過程中對於庫的搜索路徑的設置將採用第一種方式進行。這種設置方式不需要 root 權限，設置也簡單：
$ export LD_LIBRARY_PATH=/opt/gtk/lib:$LD_LIBRARY_PATH
可以用下面的命令查看 LD_LIBRAY_PATH 的設置內容：
$ echo $LD_LIBRARY_PATH
至此，庫的兩種設置就完成了。
本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/do2jiang/archive/2009/09/25/4595190.aspx