一般來說,如果庫的標頭檔不在 /usr/include 目錄中,那麼在編譯的時候需要用 -I 參數指定其路徑。由於同一個庫在不同系統上可能位於不同的目錄下,使用者安裝庫的時候也可以將庫安裝在不同的目錄下,所以即使使用同一個庫,由於庫的路徑的不同,造成了用 -I 參數指定的標頭檔的路徑也可能不同,其結果就是造成了編譯命令介面的不統一。如果使用 -L 參數,也會造成串連介面的不統一。編譯和串連介面不統一會為庫的使用帶來麻煩。
為瞭解決編譯和串連介面不統一的問題,人們找到了一些解決辦法。其基本思想就是:事先把庫的位置資訊等儲存起來,需要的時候再通過特定的工具將其中有用的資訊提取出來供編譯和串連使用。這樣,就可以做到編譯和串連介面的一致性。其中,目前最為常用的庫資訊提取工具就是下面介紹的pkg-config。
pkg-config是通過庫提供的一個 .pc 檔案獲得庫的各種必要資訊的,包括版本資訊、編譯和串連需要的參數等。這些資訊可以通過 pkg-config 提供的參數單獨提取出來直接供編譯器和連接器使用。
Thepkgconfig package contains tools for passing the include path and/or librarypaths to build tools during the make file execution.
pkg-configis a function that returns meta information for the specified library.
Thedefault setting for PKG_CONFIG_PATH is /usr/lib/pkgconfig because of the prefixwe use to install pkgconfig. You may add to PKG_CONFIG_PATH by exportingadditional paths on your system where pkgconfig files are installed. Note thatPKG_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
exportLD_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
至此,庫的兩種設定就完成了。