理解 pkg-config 工具

你在 Unix 或 Linux 下開發過軟件嗎？寫完一個程序，編譯運行徹底正常，在你本機上工做得好好的，你放到源代碼管理系統中。而後，告訴你的同事說，你能夠取下來用了。這時，你長長的出了一口氣，幾天的工做沒有白費，多麼清新的空氣啊，你開始飄飄然了。

「Hi，怎麼編譯不過去？」你還沉浸在那種美妙的感受之中，雙臂充滿着力量，彷佛沒有什麼問題能難倒你的。正在此時，那個笨蛋已經衝着你嚷開了。

「不會吧，我這邊好好的！」表面上你說得很客氣，其實，你內心已經罵開了，真笨，不知道腦子幹嗎用的。也許，你想的沒錯，上次，他犯了一個簡單的錯誤，不是你一去就解決了嗎。

他喊三次以後，你不得不放下你手上的工做，剛纔那種美妙的感受已經消失得無影無蹤了，要不是你把情緒控制得很好，一肚子氣就要撒在他身上了。你走到他的電腦前，鍵入 make，優雅的按下回車。怎麼可能出錯呢？你信心十足。然而，屏幕上的結果多少有點讓人臉紅，該死的，libxxx.so 怎麼會讓不到呢？

你在/usr目錄中查找 libxxx.so，一切都逃不過你的眼睛。奇怪，libxxx.so 怎麼在 /usr/local/lib 下，不是應該在 /usr/lib 下的嗎？這你可不能怪別人，別人想安裝在哪裏都行，下次還可能安裝到 /lib 目錄下呢。

以上的場景並不是虛構，我都經歷過好幾回，明明在本機上好好的，在別人的機器上連編譯都過不去。可能兩人的操做系統如出一轍，須要的庫都安裝上，只是因爲我的 喜愛不一樣，安裝在不一樣的目錄而已。遇到這種狀況，每次都技巧性的繞過去了，用的補丁型的方法，內心老惦記其它地方能不能工做。

今天咱們要介紹的 pkg-config，爲解決以上問題提供了一個優美方案。今後，你不再爲此擔心了。pkg-config提供了下面幾個功能：

1. 檢查庫的版本號。若是所須要的庫的版本不知足要求，它會打印出錯誤信息，避免連接錯誤版本的庫文件。

2. 得到編譯預處理參數，如宏定義，頭文件的位置。

3. 得到連接參數，如庫及依賴的其它庫的位置，文件名及其它一些鏈接參數。

4. 自動加入所依賴的其它庫的設置。

這一切都自動的，庫文件安裝在哪裏都不要緊！

在使用前，咱們說說 pkg-config 的原理，pkg-config 並不是精靈，能夠憑空獲得以上信息。事實上，爲了讓pkg-config能夠獲得這些信息，要求庫的提供者，提供一個.pc文件。好比gtk+-2.0的pc文件內容以下：

prefix=/usr
exec_prefix=/usr
libdir=/usr/lib
includedir=/usr/include
target=x11

gtk_binary_version=2.4.0
gtk_host=i386-redhat-linux-gnu

Name: GTK+
Description: GIMP Tool Kit (${target} target)
Version: 2.6.7
Requires: gdk-${target}-2.0 atk
Libs: -L${libdir} -lgtk-${target}-2.0
Cflags: -I${includedir}/gtk-2.0

這個文件通常放在 /usr/lib/pkgconfig/ 或者 /usr/local/lib/pkgconfig/ 裏，固然也能夠放在其它任何地方，如像 X11 相關的pc文件是放在 /usr/X11R6/lib/pkgconfig 下的。爲了讓pkgconfig能夠找到你的pc文件，你要把pc文件所在的路徑，設置在環境變量 PKG_CONFIG_PATH 裏。

使用 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 工具提取庫的編譯和鏈接參數有兩個基本的前提：

• 庫自己在安裝的時候必須提供一個相應的 .pc 文件(不這樣作的庫說明不支持 pkg-config 工具的使用)。

• 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+ 代替舊版沒有什麼問題的話，使用這種設置方式是比較方便的。

庫文件在鏈接（靜態庫和共享庫）和運行（僅限於使用共享庫的程序）時被使用，其搜索路徑是在系統中進行設置的。通常 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

最後，我來總結一下，PKG_CONFIG_PATH 主要指明.pc文件的所在路徑，這樣 pkg-config 工具就能夠根據.pc文件的內容動態生成編譯和鏈接選項，好比 Cflags （編譯用）和 Libs （鏈接用），若是使用的是動態連接庫，那麼程序在鏈接和運行時，通常 Linux 系統把 /lib 和 /usr/lib 兩個目錄做爲默認的庫搜索路徑，對於處於默認庫搜索路徑以外的庫，系統管理員能夠設置 LD_LIBRARY_PATH 環境變量或在 /etc/ld.so.conf 文件中添加庫的搜索路徑。值得說明的是，使用 gcc 鏈接時的選項，若是不用 pkg-config 工具，須要顯示的聲明鏈接的動態連接庫名。使用 gcc 的同窗能夠查看下面的注意事項。

Linux 系統中，爲了讓動態連接庫能被系統中其它程序共享,其名字應符合 lib*.so.* 這種格式。若是某個動態連接庫不符合此格式，則 Linux 的動態連接庫自動裝入程序（ld）將搜索不到此連接庫，其它程序也沒法共享之。格式中，第一個*一般表示爲簡寫的庫名,第二個*一般表示爲該庫的版本號。如在個人系統中，基本C動態連接庫的名字爲 libc.so.6，線程 pthread 動態連接庫的名字爲 libpthread.so.0 等等。若是沒有指定版本號，好比 libmy.so ，這也是符合要求的格式。

gcc 命令幾個重要選項:

• -shared 該選項指定生成動態鏈接庫（讓鏈接器生成T類型的導出符號表，有時候也生成弱鏈接W類型的導出符號，不用該標誌外部程序沒法鏈接。至關於一個可執行文件）。

• -fPIC：表示編譯爲位置獨立的代碼，不用此選項的話編譯後的代碼是位置相關的因此動態載入時是經過代碼拷貝的方式來知足不一樣進程的須要，而不能達到真正代碼段共享的目的。

• -L.：表示要鏈接的庫在當前目錄中。

• -lmy：編譯器查找動態鏈接庫時有隱含的命名規則，即在給出的名字前面加上lib，後面加上.so來肯定庫的名稱（libmy.so）。

固然若是有 root 權限的話，能夠修改 /etc/ld.so.conf 文件，而後調用 /sbin/ldconfig 來達到一樣的目的，不過若是沒有 root 權限，那麼只能採用輸出 LD_LIBRARY_PATH 的方法了。