第十九章、原始碼與 Tarball 套件管理員 - for Fedora Core 4

在討論程式碼是什麼之前，我們先來談論一下什麼是可執行檔？我們說過，在 Linux 系統上面，一個檔案能不能被執行看的是有沒有可執行的那個權限( 具有 x permission )，不過，Linux 系統上真正認識的可執行檔其實是二進位檔案( binary file )，例如 /usr/bin/passwd, /bin/touch 這些個檔案即為 binary 的可執行檔案！

或許您會說，咦！ shell scripts 不是也可以執行嗎？！其實 shell scripts 只是利用 shell ( 例如 bash )這支程式的功能進行一些判斷式，而最終執行的除了 bash 提供的功能外，仍是呼叫一些已經編譯好的 binary 檔案來執行的呢！( bash 本身就是 binary file 喔！) 那麼我怎麼知道一個檔案是否為 binary 呢？！還記得我們在 Linux 檔案與目錄管理 裡面提到的 file 這個指令的功能嗎？！對啦！用他就是了！我們現在來測試一下：

# 先以系統的檔案測試看看：
[root@linux ~]# file /bin/bash
/bin/bash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), 
for GNU/Linux 2.2.5, dynamically linked (uses shared libs), stripped

# 如果是系統提供的 /etc/init.d/syslog 呢？
[root@linux ~]# file /etc/init.d/syslog
/etc/init.d/syslog: Bourne-Again shell script text executable

看到了吧！如果是 binary file 而且是可以執行的時候，他就會顯示執行檔類別 ( ELF 32-bit LSB executable )，同時會說明是否使用動態函式庫( shared libs )，而如果是一般的 script ，那他就會顯示出 text executables 之類的字樣！
既然 Linux 作業系統真正認識的其實是 binary file ，那麼我們是如何做出這樣的一支 binary 的程式呢？！首先，我們必須要寫程式，用什麼東西寫程式？就是一般的文書處理器啊！我都喜歡使用 vi 來進行程式的撰寫，寫完的程式就是所謂的原始程式碼囉！ 這個程式碼檔案其實就是一般的純文字檔( text file )。 在完成這個原始碼檔案的編寫之後，再來就是要將這個檔案『 編譯』成為作業系統看的懂得 binary file 囉！而要編譯自然就需要『編譯器』來動作， 經過編譯器的編譯之後，就會產生一支可以執行的 binary file 囉。

舉個例子來說，在 Linux 上面最標準的程式語言為 C ，所以我使用 C 的語法進行原始程式碼的書寫，寫完之後，以 Linux 上標準的 C 語言編譯器 gcc 這支程式來編譯，就可以製作一支可以執行的 binary file 囉。整個的流程有點像這樣：


圖一、簡易的 gcc 編譯流程
事實上，在編譯的過程當中，還會產生所謂的目標檔( Object file )，這些檔案是以 *.o 的副檔名樣式存在的！至於 C 語言的原始碼檔案通常以 *.c 作為副檔名。此外，有的時候，我們會在程式當中『引用、呼叫』 其他的外部副程式，或者是利用其他套件提供的『函數功能』， 這個時候，我們就必須要在編譯的過程當中，將該函式庫給他加進去，如此一來， 編譯器就可以將所有的程式碼與函式庫作一個連結( Link )以產生正確的執行檔囉。

在前一小節的圖一示意圖中，在編譯的過程裡面有提到函式庫。好啦， 那麼什麼是函式庫呢？先舉個例子來說，我們的 Linux 系統上，系統通常已經提供一個可以進行身份驗證的模組，稱為 PAM ，這個 PAM 提供的功能可以讓很多的程式在被執行的時候，除了可以驗證使用者登入的資訊外， 還可以將身份確認的資料記錄在登錄檔( log file, 請查閱後續的 認識登錄檔 一文 )裡面，以方便系統管理員的追蹤！

既然有這麼好用的功能，那如果我要編寫具有身份認證功能的程式時， 直接引用該 PAM 的功能就好啦，如此一來，我就不需要重新設計認證機制囉！也就是說， 只要在我寫的程式碼裡面，設定去呼叫 PAM 的函式功能，呵呵！我的程式就可以利用 Linux 原本就有的身份認證的程序咯！除此之外，其實我們的 Linux 核心( kernel )也提供了相當多的函式庫來給硬體開發者利用喔。

函式庫又分為動態與靜態函式庫，這兩個咚咚的分別我們在後面的章節再加以說明。 這裡我們以一個簡單的流程圖，來示意一支有呼叫外部函式庫的程式的執行情況。


圖二、程式引用函式庫的示意圖
很簡單的示意圖啊！^_^！而如果要在程式裡面加入引用的函式庫，就需要如圖一所示， 亦即在編譯的過程當中，就需要加入函式庫的相關設定囉。

事實上， Linux 的核心提供很多的核心相關函式庫與外部參數， 這些核心功能在設計硬體的驅動程式的時候是相當有用的資訊，這些核心相關資訊大多放置在 /usr/include, /lib, /usr/lib 裡面哩！我們在本章的後續小節再來探討。

事實上，使用類似 gcc 的編譯器來進行編譯的過程並不簡單， 因為除了每個主程式與副程式均需要寫上一筆編譯過程的指令外，還需要寫上最終的連結程序。 程式碼小的時候還好，如果是類似 WWW 伺服器軟體( 例如 Apache )，或者是類似核心的原始碼，動則數百 MBytes 的資料量，呵呵！指令會寫到瘋掉～這個時候，我們就可以使用 make 這個指令的相關功能來進行編譯過程的指令簡化了！

當執行 make 時，make 會在當時的目錄下搜尋 Makefile ( or makefile ) 這個文字檔，而 Makefile 裡面則記錄了原始碼如何編譯的詳細資訊！  make 會自動的判別原始碼是否經過變動了，而自動更新執行檔，是軟體工程師相當好用的一個輔助工具呢！

咦！make 是一支程式，會去找 Makefile ，那 Makefile 怎麼寫？呵呵！ 通常軟體開發商都會寫一支偵測程式來偵測使用者的作業環境， 以及該作業環境是否有軟體開發商所需要的其他功能，該偵測程式偵測完畢後，就會主動的建立這個 Makefile 的規則檔案啦！通常這支偵測程式的檔名為 configure 或者是 config 。

咦！？那為什麼要偵測作業環境呢？！在 什麼是 Linux 那個章節當中， 不是有提到 Linux 不過就是一個核心嗎？！是這樣沒錯啦！但是您必須要瞭解的是， 某些軟體套件需要一些相關的套件輔助，並且，某些驅動程式則是適用在不同的核心系統( 因為核心提供的函式庫可能並不相同，例如 kernel 2.4.xx 與 kernel 2.6.xx 就不太一樣！ )，並且每個 Linux distribution 所提供的函式庫名稱與路徑可能也不太一樣，所以說，在 Fedora Core 4 上面可以執行的一個 binary file ，直接複製到 SuSE 平台上，可不見得可以順利執行( 事實上，是不太可能可以執行啦！^_^ )。 所以啦，原始碼寫出來之後，需要針對不同的作業環境來進行編譯的行為吶！這個時候就很需要 configure 以及 make 的功能啊！

詳細的 make 用法與 Makefile 規則，在後續的小節裡面再探討囉！

從前面幾個小節的說明來看，我們知道所謂的原始程式碼，其實就是一些寫滿了程式碼的純文字檔案。那我們從前面的 檔案的壓縮與打包 章節當中，也瞭解了純文字檔其實是很浪費硬碟空間的一種檔案格式！( 想一想，一個核心的原始碼檔案大約要 200~300 MB 以上，如果每個人都去下載這樣的一個核心檔案， 呵呵！那麼網路頻寬不被吃的死翹翹才怪呢！ ) 所以啦，如果能夠將這些原始碼透過檔案的打包與壓縮技術來將檔案的數量與容量減小， 不但讓使用者容易下載，套件開發商的網站頻寬也能夠節省很多很多啊！這就是 Tarball 檔案的由來囉！

所謂的 Tarball 檔案，其實就是將套件的所有原始碼檔案先以 tar 打包，然後再以壓縮技術來壓縮，通常最常見的就是以 gzip 來壓縮了。因為利用了 tar 與 gzip 的功能，所以 tarball 檔案一般的副檔名就會寫成 *.tar.gz 或者是簡寫為 *.tgz 囉！也就是說， Tarball 套件解壓縮之後，裡面的檔案通常就會有：

• 原始程式碼檔案；
• 偵測程式檔案( 可能是 configure 或 config 等檔名 )；
• 本套件的簡易說明與安裝說明( INSTALL 或 README )。

其中最重要的是那個 INSTALL 或者是 README 這兩個檔案，通常您只要能夠參考這兩個檔案，呵呵！ Tarball 套件的安裝是很簡單的啦！我們在後面的章節會再繼續介紹 Tarball 這個玩意兒。

將原始碼作了一個簡單的介紹，也知道了系統其實認識的可執行檔是 binary file 之後，好了，得要聊一聊，那麼怎麼安裝與升級一個 Tarball 的套件？為什麼要安裝一個新的套件呢？當然是因為我們的主機上面沒有該套件囉！那麼， 為何要升級呢？！原因可能有底下這些：

• 需要新的功能，但舊有主機的舊版套件並沒有，所以需要升級到新版的套件；
• 舊版本的套件上面可能有安全上的顧慮，所以需要更新到新版的套件；
• 舊版的套件執行效能不彰，或者執行的能力不能讓管理者滿足。

在上面的需求當中，尤其需要注意的是第二點，當一個套件有安全上的顧慮時，千萬不要懷疑， 趕緊更新套件吧！否則造成網路危機，那可不是鬧著玩的！那麼更新的方法有哪些呢？ 基本上更新的方法可以分為兩大類，分別是：

• 直接以原始碼透過編譯來安裝與升級；
• 直接以編譯好的 binary file 來安裝與升級。

上面第一點很簡單，就是直接以 Tarball 在自己的機器上面進行偵測、編譯、 安裝與設定等等動作來升級就是了。不過，這樣的動作雖然讓使用者在安裝過程當中具有很高的彈性， 但畢竟是比較麻煩一點，如果 Linux distribution 廠商能夠針對自己的作業平台先進行編譯等過程，再將編譯好的 binary file 釋出的話，那由於我的系統與該 Linux distribution 的環境是相同的，所以他所釋出的 binary file 就可以在我的機器上面直接安裝啦！省略了偵測與編譯等等繁雜的過程呢！

目前很多 binary file 升級的機制呢，包括有 Red Hat 系統 ( 含 Fedora 系列 ) 發展的 RPM 與 up2date, yum 等線上更新模式；Mandrake 的 urpmi 套件更新方式； Debian 使用的 dpkg ； Sun Unix 使用的 pkg ，以及目前很流行的 apt 線上更新模式等等， 以使用率來說，目前最傳統的是以 Tarball 直接進行編譯的安裝與升級，而另一個則是以 RPM 相關的機制來進行安裝與升級囉！本章節主要針對 Tarball ，至於 RPM 則留待下個章節再來介紹呢！

好了，那麼一個套件的 Tarball 是如何安裝的呢？基本流程是這樣的啦：

1. 將 Tarball 由廠商的網頁下載下來；
2. 將 Tarball 解開，產生很多的原始碼檔案；
3. 開始以 gcc 進行原始碼的編譯( 會產生目標檔 object files )；
4. 然後以 gcc 進行函式庫、主、副程式的連結，以形成主要的 binary file；
5. 將上述的 binary file 以及相關的設定檔安裝至自己的主機上面。

上面第 3, 4 步驟當中，我們可以透過 make 這個指令的功能來簡化他， 所以整個步驟其實是很簡單的啦！只不過您就得需要至少有 gcc 以及 make 這兩個套件在您的 Linux 系統裡面才行喔！ 詳細的過程以及需要的套件我們在後面的章節繼續來介紹的啦！

我們以 Linux 上面最常見的 C 語言來撰寫第一支程式！第一支程式最常作的就是..... 在螢幕上面印出『Hello World！』的字樣～當然， 這裡我們是以簡單的 C 語言來撰寫，如果您對於 C 有興趣的話，那麼請自行購買相關的書籍喔！ ^_^好了，不囉唆，立刻編輯第一支程式吧！ ( 請先確認您的 Linux 系統裡面已經安裝了 gcc 了喔！如果尚未安裝 gcc 的話，請先參考下一節的 RPM 安裝法，先安裝好 gcc 之後，再回來閱讀本章 )

# 1. 先編輯原始碼：
[root@linux ~]# vi hello.c   <==注意一下， C 語言用 .c 的副檔名
#include <stdio.h>
int main(void)
{
        printf("Hello World\n");
}

# 上面是 C 語言的語法，那個第一行的 # 並不是註解喔！如果您擔心
# 輸入錯誤，請到底下的連結下載這個檔案：
# http://linux.vbird.org/linux_basic/0520source/hello.c

# 2. 開始將原始碼編譯成為可執行的 binary file ：
[root@linux ~]# gcc hello.c
# 這個時候，在本目錄下會產生一個名為 a.out 的執行檔！
# 在預設的狀態下，如果我們直接以 gcc 編譯原始碼，並且沒有加上
# 任何參數，則 執行檔的檔名會被自動設定為 a.out 這個檔案名稱！

# 3. 執行一下這個檔案：
[root@linux ~]# ./a.out
Hello World  <==呵呵！成果出現了！

好了，上面的例子很簡單吧！那個 hello.c 就是原始碼，而 gcc 就是編譯器，至於 a.out 就是編譯成功的可執行 binary file 囉！咦！如果我想要產生目標檔( object file )來進行其他的動作( 在較大的套件當中， 就需要使用多個目標檔來進行相關的連結)，而且執行檔的檔名也不要用預設的 a.out ，那該如何是好？可以將上面的第 2 個步驟改成這樣：

[root@linux ~]# gcc -c hello.c
# 會產生一個名為 hello.o 的目標檔，object file 的副檔名為 *.o 喔！

[root@linux ~]# gcc -o hello hello.o
# 這個步驟是利用 hello.o 這個目標檔製作出一個名為 hello 的執行檔
# 詳細的 gcc 語法我們會在後續章節中繼續介紹！
# 透過這個動作後，我們可以得到 hello 及 hello.o 兩個檔案，
# 真正可以執行的是 hello 這個 binary file 喔！

# 3. 執行一下這個檔案：
[root@linux ~]# ./hello
Hello World

或許您會覺得，咦！只要一個動作作出 a.out 就好了，幹嘛還要先製作目標檔再做成執行檔呢？！ 呵呵！透過下個範例，您就可以知道為什麼啦！

如果我們在一個主程式裡面又呼叫了另一個副程式呢！？這是很常見的一個程式寫法， 因為可以簡化整個程式的易讀性！在底下的例子當中，我們以 thanks.c 這個主程式去呼叫 thanks_2.c 這個副程式，寫法很簡單：

# 1. 先編輯原始碼 thanks.c 與 thanks_2.c：
[root@linux ~]# vi thanks.c
#include <stdio.h>
int main(void)
{
        printf("Hello World\n");
        thanks_2();
}
# 上面的 thanks_2(); 那一行就是呼叫副程式啦！

[root@linux ~]# vi thanks_2.c
void thanks_2(void)
{
        printf("Thank you!\n");
}
# 上面這兩個檔案您可以到底下下載：
# http://linux.vbird.org/linux_basic/0520source/thanks.c
# http://linux.vbird.org/linux_basic/0520source/thanks_2.c

# 2. 開始將原始碼編譯成為可執行的 binary file ：
[root@linux ~]# gcc -c thanks.c thanks_2.c
# 產生了兩個目標檔！且編譯過程裡面可能會產生一些 warning (警告) 的訊息，
# 因為僅是警告而已，所以該訊息你可以先略過去不打緊的！ ^_^
[root@linux ~]# gcc -o thanks thanks.o thanks_2.o

# 3. 執行一下這個檔案：
[root@linux ~]# ./thanks
Hello World
Thank you!

知道為什麼要製作出目標檔了嗎？！由於我們的原始碼檔案有時並非僅只有一個檔案， 所以我們無法直接進行編譯。這個時候就需要先產生目標檔，然後再以連結製作成為 binary 可執行檔。另外，如果有一天，您更新了 thanks_2.c 這個檔案的內容，則您只要重新編譯 thanks_2.c 來產生新的 thanks_2.o ，然後再以連結製作出新的 binary 可執行檔即可！而不必重新編譯其他沒有更動過的原始碼檔案。 這對於軟體開發者來說，是一個很重要的功能，因為有時候要將偌大的原始碼全部編譯完成， 會花很長的一段時間呢！

此外，如果您想要讓程式在執行的時候具有比較好的效能，或者是其他的除錯功能時， 可以在編譯的過程裡面加入適當的參數，例如底下的例子：

[root@linux ~]# gcc -O -c thanks.c thanks_2.c
# -O 為產生最佳化的參數

[root@linux ~]# gcc -Wall -c thanks.c thanks_2.c
thanks.c: In function 'main':
thanks.c:5: warning: implicit declaration of function 'thanks_2'
thanks.c:6: warning: control reaches end of non-void function
thanks_2.c: In function 'thanks_2':
thanks_2.c:3: warning: implicit declaration of function 'printf'
thanks_2.c:3: warning: incompatible implicit declaration of built-in function 'printf'
# -Wall 為產生更詳細的編譯過程資訊。上面的訊息為警告訊息( warning )
# 所以不用理會也沒有關係！

至於更多的 gcc 額外參數功能，就得要 man gcc 囉～呵呵！可多的跟天書一樣～

剛剛我們都僅只是在螢幕上面印出一些字眼而已，如果說要計算數學公式呢？！ 例如我們想要計算出三角函數裡面的 sin(90度角)，要注意的是，大多數的程式語言都是使用徑度而不是一般我們在計算的『角度』， 180 度角約等於 3.14 徑度！嗯！那我們就來寫一下這個程式吧！

[root@linux ~]# vi sin.c
#include <stdio.h>
int main(void)
{
        float value;
        value = sin ( 3.14 / 2 );
        printf("%f\n",value);
}
# 上面這個檔案的內容可以在底下取得！
# http://linux.vbird.org/linux_basic/0520source/sin.c

那要如何編譯這支程式呢？我們先直接編譯看看：

[root@linux ~]# gcc sin.c
sin.c: In function 'main':
sin.c:5: warning: incompatible implicit declaration of built-in function 'sin'
/tmp/cciDlilg.o(.text+0x2c): In function `main':
sin.c: undefined reference to `sin'
collect2: ld returned 1 exit status
# 注意看到上面最後一行，會有個錯誤訊息，代表沒有成功！

特別注意上面的錯誤訊息，唉啊！怎麼沒有編譯成功？它說的是『undefined reference to sin』，說的是『沒有 sin 的相關定義參考值！』，為什麼會這樣呢？這是因為 C 語言裡面的 sin 函示是寫在 libm.so 這個函式庫中，而我們並沒有在原始碼裡面加入相關的說明， 所以當然就需要在編譯與連結的時候將這個函式庫給他連結進執行檔裡面啊！所以我們可以這樣做：

[root@linux ~]# gcc sin.c -lm -L/lib -L/usr/lib
# 特別注意，那個 -lm 可以拆開成兩部份來看：
# -l ：是『加入某個函式庫(library)』的意思，而
# m  ：則是 libm.so 這個函式庫，其中， lib 與副檔名(.a 或 .so)不需要寫
# 所以 -lm 表示使用 libm.so (或 libm.a) 這個函式庫的意思～
# 至於那個 -L 後面接的路徑呢？這表示：
#『我要的函式庫 libm.so 請到 /lib 或 /usr/lib 裡面搜尋！』
[root@linux ~]# ./a.out
1.000000

上面的說明很清楚了吧！！不過，要注意的是，由於 Linux 預設是將函式庫放置在 /lib 與 /usr/lib 當中，所以您沒有寫 -L/lib 與 -L/usr/lib 也沒有關係的！不過，萬一哪天您使用的函式庫並非放置在這兩個目錄下，那麼 -L/path 就很重要了！否則會找不到函式庫喔！

除了連結的函式庫之外，您或許已經發現一個奇怪的地方，那就是在我們的 sin.c 當中第一行『 #include <stdio.h>』，這行說的是要將一些定義資料由 stdio.h 這個檔案讀入，這包括 printf 的相關設定。這個檔案其實是放置在 /usr/include/stdio.h 的！那麼萬一這個檔案並非放置在這裡呢？那麼我們就可以使用底下的方式來定義出要讀取的 include 檔案放置的目錄：

[root@linux ~]# gcc sin.c -lm -I/usr/include

-I/path 後面接的路徑( Path )就是設定要去搜尋相關的 include 檔案的目錄啦！不過，同樣的，預設值是放置在 /usr/include 底下，除非您的 include 檔案放置在其他路徑，否則也可以略過這個項目！

透過上面的幾個小範例，您應該對於 gcc 以及原始碼有一定程度的認識了，再接下來，我們來稍微整理一下 gcc 的簡易使用方法吧！

前面說過， gcc 為 Linux 上面最標準的編譯器，這個 gcc 是由 GNU 所維護的，有興趣的朋友請自行前往參考。既然 gcc 對於 Linux 上的 Open source 是這麼樣的重要，所以底下我們就列舉幾個 gcc 常見的參數，如此一來大家應該更容易瞭解原始碼的各項功能吧？！

# 僅將原始碼編譯成為目標檔，並不製作連結等功能：
[root@linux ~]# gcc -c hello.c
# 會自動的產生 hello.o 這個檔案，但是並不會產生 binary 執行檔。

# 在編譯的時候，依據作業環境給予最佳化執行速度
[root@linux ~]# gcc -O hello.c -c
# 會自動的產生 hello.o 這個檔案，並且進行最佳化喔！

# 在進行 binary file 製作時，將連結的函式庫與相關的路徑填入
[root@linux ~]# gcc sin.c -lm -L/usr/lib -I/usr/include
# 這個指令較常下達在最終連結成 binary file 的時候，
# -lm 指的是 libm.so 或 libm.a 這個函式庫檔案；
# -L 後面接的路徑是剛剛上面那個函式庫的搜尋目錄；
# -I 後面接的是原始碼內的 include 檔案之所在目錄。

# 將編譯的結果輸出成某個特定檔名
[root@linux ~]# gcc -o hello hello.c
# -o 後面接的是要輸出的 binary file 檔名

# 在編譯的時候，輸出較多的訊息說明
[root@linux ~]# gcc -o hello hello.c -Wall
# 加入 -Wall 之後，程式的編譯會變的較為嚴謹一點，
# 所以警告訊息也會顯示出來！

比較重要的大概就是這一些。另外，我們通常稱 -Wall 或者 -O 這些非必要的參數為旗標( FLAGS )，因為我們使用的是 GCC ，所以有時候也會簡稱這些旗標為 CFLAGS ，這些變數偶爾會被使用的喔！尤其是在後頭會介紹的 make 相關的用法時，更是重要的很吶！ ^_^

先來想像一個案例，假設我的執行檔裡面包含了四個原始碼檔案，分別是 main.c haha.c sin_value.c cos_value.c 這四個檔案，這四個檔案您可以到 http://linux.vbird.org/linux_basic/0520source/main.tgz 來下載，由於這四個檔案裡面包含了相關性，並且還用到數學函式在裡面， 所以如果您想要讓這個程式可以跑，那麼就需要這樣編譯：

[root@linux ~]# gcc -c main.c
[root@linux ~]# gcc -c haha.c
[root@linux ~]# gcc -c sin_value.c
[root@linux ~]# gcc -c cos_value.c
# 先以上面的動作製作出四個目標檔，然後再進行下面的動作：

[root@linux ~]# gcc -o main main.o haha.o sin_value.o cos_value.o \
> -lm -L/usr/lib -L/lib
# 這樣就可以製作出  main 這個執行檔囉！執行看看吧！

[root@linux ~]# ./main 
HaHa! I'm the King of the world
0.706825
0.707388

呵呵！要做好多動作啊！真是麻煩，如果可以的話，能不能一個步驟就給他完成上面所有的動作呢？ 試看看在這個目錄下建立一個 makefile 檔案，內容如下：

# 1. 先建立編譯的規則
[root@linux ~]# vi makefile
main: main.o haha.o sin_value.o cos_value.o
	gcc -o main main.o haha.o sin_value.o cos_value.o -lm
# 注意：第二行的 gcc 之前是 <tab> 按鍵產生的空格喔！

# 2. 嘗試給他建立規則看看
[root@linux ~]# rm -f main *.o   <==先將之前的目標檔去除
[root@linux ~]# make
cc    -c -o main.o main.c
cc    -c -o haha.o haha.c
cc    -c -o sin_value.o sin_value.c
cc    -c -o cos_value.o cos_value.c
gcc -o main main.o haha.o sin_value.o cos_value.o -lm
# 這個時候 make 會主動去讀取 makefile 這個檔案的內容，
# 並根據內容直接去給他編譯起相關的執行檔囉！

# 3. 如果再執行一次 make 會怎樣？！
[root@linux ~]# make
make: `main' is up to date.
# 看到了吧？！是否很方便呢？！

或許您會說：『如果我建立一個 shell script 來將上面的所有動作都集結在一起， 不是具有同樣的效果嗎？』呵呵！效果當然不一樣，以上面的測試為例，我們僅寫出 main 需要的目標檔，結果 make 會主動的去判斷每個目標檔相關的原始碼檔案，並直接予以編譯， 最後再直接進行連結的動作！哈哈！真的是很方便啊！此外，如果我們更動過某些原始碼檔案，則 make 也可以主動的判斷哪一個原始碼與相關的目標檔檔案有更新過， 並僅更新該檔案，如此一來，將可大大的節省很多編譯的時間呢！要知道，某些程式在進行編譯的行為時，會消耗很多的 CPU 資源呢！所以說， make 有這些好處：

• 簡化編譯時所需要下達的指令；
• 若在編譯完成之後，修改了某個原始碼檔案，則 make 僅會針對被修改了的檔案進行編譯，其他的 object file 不會被更動；
• 最後可以依照相依性來更新( update )執行檔。

既然 make 有這麼多的優點，那麼我們當然就得好好的瞭解一下 make 這個令人關心的傢伙啦！而 make 裡面最需要注意的大概就是那個規則檔案，也就是 makefile 這個檔案的語法啦！底下我們針對 makefile 的語法來加以介紹囉。

make 的語法可是相當的多而複雜的，有興趣的話可以到 http://www.gnu.org/software/make/manual/make.html 去查閱相關的說明，鳥哥這裡僅列出一些基本的規則，重點在於讓讀者們未來在接觸原始碼時，不會太緊張啊！ ^_^好了，基本的 makefile 規則是這樣的：

標的(target): 目標檔1 目標檔2
<tab>   gcc -o 欲建立的執行檔 目標檔1 目標檔2

那個標的(target)就是我們想要建立的資訊，而目標檔就是具有相關性的 object files ，那建立執行檔的語法就是以 <tab> 按鍵開頭的那一行！特別給他留意喔， 『命令列必須要以 tab 按鍵作為開頭』才行！ 他的規則基本上是這樣的：

• 在 makefile 當中的 # 代表註解；
• <tab> 需要在命令行的第一個字元；
• 標的(target)與相依檔案(就是目標檔)之間需以『:』隔開。

同樣的，我們以剛剛上一個小節的範例進一步說明，如果我想要有兩個以上的執行動作時， 例如下達一個指令就直接清除掉所有的目標檔與執行檔，該如何製作呢？

# 1. 先建立編譯的規則
[root@linux ~]# vi makefile
main: main.o haha.o sin_value.o cos_value.o
	gcc -o main main.o haha.o sin_value.o cos_value.o -lm
clean:
	rm -f main main.o haha.o sin_value.o cos_value.o

# 2. 測試看看：
[root@linux ~]# make clean
rm -rf main main.o haha.o sin_value.o cos_value.o

如此一來，我們的 makefile 裡面就具有至少兩個標的，分別是 main 與 clean ，如果我們想要建立 main 的話，輸入『make main』，如果想要清除有的沒的，輸入『make clean』即可啊！而如果想要先清除目標檔再編譯 main 這個程式的話，就可以這樣輸入：『make clean main』，如下所示：

[root@linux ~]# make clean main
rm -rf main main.o haha.o sin_value.o cos_value.o
cc    -c -o main.o main.c
cc    -c -o haha.o haha.c
cc    -c -o sin_value.o sin_value.c
cc    -c -o cos_value.o cos_value.c
gcc -o main main.o haha.o sin_value.o cos_value.o -lm

這樣就很清楚了吧！？但是，您是否會覺得，咦！ makefile 裡面怎麼重複的資料這麼多啊！呵呵！沒錯！所以我們可以再藉由 shell script 那時學到的『變數』來更簡化 makefile 喔：

[root@linux ~]# vi makefile
LIBS = -lm
OBJS = main.o haha.o sin_value.o cos_value.o
main: ${OBJS}
        gcc -o main ${OBJS} ${LIBS}
clean:
        rm -f main ${OBJS}

與 bash shell script 的語法有點不太相同，變數的基本語法為：

1. 變數與變數內容以『=』隔開，同時兩邊可以具有空格；
2. 變數左邊不可以有 <tab> ，例如上面範例的第一行 LIBS 左邊不可以是 <tab>；
3. 變數與變數內容在『=』兩邊不能具有『:』；
4. 在習慣上，變數最好是以『大寫字母』為主；
5. 運用變數時，以 ${變數} 或 $(變數) 使用；
6. 在該 shell 的環境變數是可以被套用的，例如提到的 CFLAGS 這個變數！
7. 在指令列模式也可以給予變數。

由於 gcc 在進行編譯的行為時，會主動的去讀取 CFLAGS 這個環境變數，所以，您可以直接在 shell 定義出這個環境變數，也可以在 makefile 檔案裡面去定義，更可以在指令列當中給予這個咚咚呢！例如：

[root@linux ~]# CFLAGS="-Wall" make clean main
# 這個動作在上 make 進行編譯時，會去取用 CFLAGS 的變數內容！

也可以這樣：

[root@linux ~]# vi makefile
LIBS = -lm
OBJS = main.o haha.o sin_value.o cos_value.o
CFLAGS = -Wall
main: ${OBJS}
	gcc -o main ${OBJS} ${LIBS}
clean:
	rm -f main ${OBJS}

咦！我可以利用指令列進行環境變數的輸入，也可以在檔案內直接指定環境變數，那萬一這個 CFLAGS 的內容在指令列與 makefile 裡面並不相同時，以那個方式輸入的為主？呵呵！ 環境變數取用的規則是這樣的：

1. make 指令列後面加上的環境變數為優先；
2. makefile 裡面指定的環境變數第二；
3. shell 原本具有的環境變數第三。

此外，還有一些特殊的變數需要瞭解的喔：

• $@：代表目前的標的(target)

所以我也可以將 makefile 改成：

[root@linux ~]# vi makefile
LIBS = -lm
OBJS = main.o haha.o sin_value.o cos_value.o
CFLAGS = -Wall
main: ${OBJS}
	gcc -o $@ ${OBJS} ${LIBS}   <==那個 $@ 就是 main ！
clean:
	rm -f main ${OBJS}

這樣是否稍微瞭解了 makefile ( 也可能是 Makefile ) 的基本語法？這對於您未來自行修改原始碼的編譯規則時，是很有幫助的喔！^_^！

從原始碼的說明我們曉得要製作一個 binary 執行檔需要很多咚咚的呢！這包括底下這些基礎的套件：

• gcc 或 cc 等 C 語言編譯器( compiler )：
  這是一定要的啦！要將原始碼編譯成為可執行的 binary 才行，所以當然就需要編譯器囉！在 Linux 上面用的當然就是 GNU 發展的 gcc 這個超好用的免費的 C 編譯器啦！並且，很多在 Linux 平台上面發展的套件的原始碼，原本就是以 gcc 為底來設計的呢。


• make 及 autoconfig 等套件：
  一般來說，以 Tarball 方式釋出的套件當中，為了簡化編譯的行程，通常都是配合前幾個小節提到的 make 這個指令來依據目標檔案的相依性而進行編譯。但是我們也知道說 make 需要 makefile 這個檔案的規則，那由於不同的系統裡面可能具有的基礎套件環境並不相同， 所以就需要偵測使用者的作業環境，好自行建立一個 makefile 檔案。這個自行偵測的小程式也必須要藉由 autoconfig 這個相關的套件來輔助才行。


• 需要 Kernel 提供的 Library 以及相關的 Include 檔案：
  從前面的原始碼編譯過程，我們曉得函式庫( library )的重要性，同時也曉得有 include 檔案的存在。很多的套件在發展的時候都是直接取用系統核心提供的函式庫與 include 檔案的，這樣才可以與這個作業系統相容啊！尤其是在『 驅動程式方面的套件 』，例如網路卡、音效卡、USB 等驅動程式在安裝的時候，常常是需要核心提供的相關資訊的。在 Red Hat 的系統當中 ( 包含 Fedora 等系列 ) ，這個核心相關的功能通常都是被包含在 kernel-source 或 kernel-header 這些套件名稱當中，所以記得要安裝這些套件喔！

雖然 Tarball 的安裝上面相當的簡單，如同我們前面幾個小節的例子，只要順著開發商提供的 README 與 INSTALL 檔案所載明的步驟來進行，安裝是很容易的。但是我們卻還是常常會在 BBS 或者是新聞群組當中發現這些留言：『我在執行某個程式的偵測檔案時，他都會告訴我沒有 gcc 這個套件，這是怎麼回事？』還有：『我沒有辦法使用 make 耶！這是什麼問題？』呵呵！ 這就是沒有安裝上面提到的那些基礎套件啦！

咦！為什麼使用者不安裝這些套件啊？呵呵！這是因為目前的 Linux distribution 大多已經偏向於桌上型電腦的使用，他們希望使用者能夠按照廠商自己的希望來安裝相關的套件即可， 所以通常『預設』是沒有安裝 gcc 或者是 make 等套件的。所以啦，如果您希望未來可以自行安裝一些以 Tarball 方式釋出的套件時，記得請自行挑選想要安裝的套件名稱喔！例如在 Fedora 或者是 Red Hat 當中記得選擇 Software Development 以及 Kernel Source Development 等相關字眼的群集呢。

那萬一我已經安裝好一部 Linux 主機，但是使用的是預設值所安裝的套件，所以沒有 make, gcc 等咚咚，該如何是好？呵呵！問題其實不大啦，目前使用最廣泛的 Fedora 或者是 Red Hat 大多是以 RPM ( 下一章會介紹 ) 來安裝套件的，所以，您只要拿出當初安裝 Linux 時的原版光碟，然後以下一章介紹的 RPM 來一個一個的加入到您的 Linux 主機裡面就好啦！很簡單的啦！

我們提過以 Tarball 方式釋出的套件是需要重新編譯可執行的 binary file 的。而 Tarball 是以 tar 這個指令來打包與壓縮的檔案，所以啦，當然就需要先將 Tarball 解壓縮，然後到原始碼所在的目錄下進行 makefile 的建立，再以 make 來進行編譯與安裝的動作啊！所以整個安裝的基礎動作大多是這樣的：

1. 將 tarball 檔案在 /usr/local/src 目錄下解壓縮；
2. 進入新建立的目錄底下，去查閱 INSTALL 與 README 等相關檔案內容( 很重要的步驟！ )；
3. 根據 INSTALL/README 的內容察看並安裝好一些相依的套件( 非必要 )；
4. 以自動偵測程式( configure 或 config )偵測作業環境，並建立 Makefile 這個檔案；
5. 以 make 這個程式並使用該目錄下的 Makefile 做為他的參數設定檔，來進行 make ( 編譯或其他 )的動作；
6. 以 make 這個程式，並以 Makefile 這個參數設定檔，依據 install 這個標的( target )的指定來安裝到正確的路徑！

注意到上面的第二個步驟，通常在每個軟體在釋出的時候，都會附上 INSTALL 或者是 README 這種檔名的說明檔，這些說明檔請『確實詳細的』 閱讀過一遍，通常這些檔案會記錄這個軟體的安裝要求、軟體的工作項目、 與軟體的安裝參數設定及技巧等，只要仔細的讀完這些檔案，基本上，要安裝好 tarball 的檔案，都不會有什麼大問題囉。至於 makefile 在製作出來之後，裡頭會有相當多的標的( target )，最常見的就是 install 與 clean 囉！通常『make clean』代表著將目標檔( object file )清除掉，『make』則是將原始碼進行編譯而已。 注意喔！編譯完成的可執行檔與相關的設定檔還在原始碼所在的目錄當中喔！因此，最後要進行『make install』來將編譯完成的所有咚咚都給他安裝到正確的路徑去，這樣就可以使用該套件啦！

OK！我們底下約略提一下大部分的 tarball 軟體之安裝的指令下達方式：

1. ./configure
   這個步驟就是在建立 Makefile 這的檔案囉！通常程式開發者會寫一支 scripts 來檢查您的 Linux 系統、相關的套件屬性等等，這個步驟相當的重要， 因為未來您的安裝資訊都是這一步驟內完成的！另外，這個步驟的相關資訊應該要參考一下該目錄下的 README 或 INSTALL 相關的檔案！！基本上，這個步驟完成之後會建立( 或修改 )一個 Makefile ，這就是參數檔啦！


2. make clean
   make 會讀取 Makefile 中關於 clean 的工作。這個步驟不一定會有，但是希望執行一下！ 為什麼呢？因為在進行編譯的時候，會產生一些 *.o 的檔案，例如有個 abc.c 的原始碼，經過編譯後會產生 abc.o 的檔案！我們稱這些檔案為 object file ，這些檔案如果之前已經編譯過並留下來的話，那麼這次再編譯的時候， 就不會編譯該檔案，然而由於我們可能已經修改了部分的參數，因此該檔案的編譯結果事實 上應該會有所不同！因此，為了避免前一次留下來的資料可能影響到這次編譯的結果， 所以通常可以進行一下這個步驟囉！


3. make
   make 會依據 Makefile 當中的預設工作進行編譯的行為！編譯的工作主要是進行 gcc 來將原始碼編譯成為可以被執行的 object files ，但是這些 object files 通常還需要一些函式庫之類的 link 後，才能產生一個完整的執行檔！使用 make 就是要將原始碼編譯成為可以被執行的可執行檔，而這個可執行檔會放置在目前所在的目錄之下， 尚未被安裝到預定安裝的目錄中；


4. make install
   通常這就是最後的安裝步驟了，make 會依據 Makefile 這個檔案裡面關於 install 的項目，將上一個步驟所編譯完成的資料給他安裝到預定的目錄中， 就完成安裝啦！

請注意，上面的步驟是一步一步來進行的，而 其中只要一個步驟無法成功，那麼後續的步驟就完全沒有辦法進行的！ 因此，要確定每一的步驟都是成功的才可以！舉個 例子來說，萬一今天你在 ./configure 就不成功了，那麼就表示 Makefile 無法被建立起來，要知道，後面的步驟都是根據 Makefile 來進行的，既然無法建立 Makefile ，後續的步驟當然無法成功囉！另外，如果在 make 無法成功的話，那就表示原始檔案無法被編譯成可執行檔，那麼 make install 主要是將編譯完成的檔案給他安裝下去的，既然都沒有成功的執行檔了，怎麼進行安裝？ 所以囉，要每一個步驟都正確無誤才能往下繼續做！此外，如果安裝成功， 並且是安裝在獨立的一個目錄中，例如 /usr/local/packages 這個目錄中好了，那麼您就必需手動的將這個套件的 man page 給他放到 /etc/man.config 裡面去。

或許您已經發現了也說不定，那就是為什麼前一個小節裡面， Tarball 要在 /usr/local/src 裡面解壓縮呢？呵呵！基本上，在預設的情況下，原本的 Linux distribution 釋出安裝的套件大多是在 /usr 裡面的，而使用者自行安裝的套件則建議放置在 /usr/local 裡面。這是考量到管理使用者所安裝套件的便利性。

怎麼說呢？我們曉得幾乎每個套件都會提供線上說明的服務，那就是 info 與 man 的功能。在預設的情況下， man 會去搜尋 /usr/local/man 裡面的說明文件， 因此，如果我們將套件安裝在 /usr/local 底下的話，那麼自然安裝完成之後， 該套件的說明文件就可以被找到了。此外，如果您所管理的主機其實是由多人共同管理的， 或者是如同學校裡面，一部主機是由學生管理的，但是學生總會畢業吧？ 所以需要進行交接，如果大家都將套件安裝在 /usr/local 底下，那麼管理上不就顯的特別的容易嗎？！

所以囉，通常我們會建議大家將自己安裝的套件放置在 /usr/local 下，至於原始碼( Tarball )則建議放置在 /usr/local/src( src 為 source 的縮寫 )底下啊。

再來，讓我們先來看一看 Linux distribution 預設的安裝套件的路徑會用到哪些？我們以 apache 這個軟體來說明的話( apache 是 WWW 伺服器軟體，詳細的資料請參考伺服器架設篇。 您的系統不見得有裝這個套件 )：

• /etc/httpd
• /usr/lib
• /usr/bin
• /usr/share/man

我們會發現套件的內容大致上是擺在 etc, lib, bin, man 等目錄當中，分別代表『設定檔、函式庫、執行檔、線上說明檔』。 好了，那麼你是以 tarball 來安裝時呢？如果是放在預設的 /usr/local 裡面，由於 /usr/local 原本就預設這幾個目錄了，所以你的資料就會被放在：

• /usr/local/etc
• /usr/local/bin
• /usr/local/lib
• /usr/local/man

但是如果你每個套件都選擇在這個預設的路徑下安裝的話， 那麼所有的套件的檔案都將放置在這四個目錄當中，因此，如果你都安裝在這個目錄下的話， 那麼未來再想要升級或移除的時候，就會比較難以追查檔案的來源囉！ 而如果您在安裝的時候選擇的是單獨的目錄，例如我將 apache 安裝在 /usr/local/apache 當中，那麼您的檔案目錄就會變成：

• /usr/local/apache/etc
• /usr/local/apache/bin
• /usr/local/apache/lib
• /usr/local/apache/man

呵呵呵呵！單一套件的檔案都在同一個目錄之下，那麼要移除該套件就簡單的多了！ 只要將該目錄移除即可視為該套件已經被移除囉 ！以上面為例，我想要移除 apache 只要下達『rm -rf /usr/local/apache』 就算移除這個套件啦！當然囉，實際安裝的時候還是得視該軟體的 Makefile 裡頭的 install 資訊才能知道到底他的安裝情況為何的。因為例如 sendmail 的安裝就很麻煩......這個方式雖然有利於套件的移除，但不曉得您有沒有發現， 我們在執行某些指令的時候，與該指令是否在 PATH 這個環境變數所記錄的路徑有關，以上面為例，我的 /usr/local/apache/bin 肯定是不在 PATH 裡面的，所以執行 apache 的指令就得要利用絕對路徑了，否則就得將這個 /usr/local/apache/bin 加入 PATH 裡面。另外，那個 /usr/local/apache/man 也需要加入 man page 搜尋的路徑當中啊！

除此之外， Tarball 在升級的時候也是挺困擾的，怎麼說呢？我們還是以 apache 來說明好了。WWW 伺服器為了考慮互動性，所以通常會將 PHP+MySQL+Apache 一起安裝起來( 詳細的資訊請參考伺服器架設篇 )，果真如此的話，那麼每個套件在安裝的時候『 都有一定的順序與程序！』因為他們三者之間具有相關性， 所以安裝時必需要三者同時考慮到他們的函式庫與相關的編譯參數。那麼如果今天我只要升級 PHP 呢？有的時候因為只有涉及動態函式庫的升級，那麼我只要升級 PHP 即可！其他的部分或許影響不大。但是如果今天 PHP 需要重新編譯的模組比較多，那麼可能會連帶的，連 Apache 這個程式也需要重新編譯過才行！真是有點給他頭痛的！沒辦法啦！使用 tarball 確實有他的優點啦，但是在這方面，確實也有他一定的傷腦筋程度。

由於 Tarball 在升級與安裝上面具有這些特色，亦即 Tarball 在反安裝上面具有比較高的難度( 如果您沒有好好規劃的話～ )，所以，為了方便 Tarball 的管理，通常我們會這樣建議使用者：

1. 最好將 tarball 的原始資料解壓縮到 /usr/local/src 當中；


2. 安裝時，最好安裝到 /usr/local 這個預設路徑下；


3. 考慮未來的反安裝步驟，最好可以將每個套件單獨的安裝在 /usr/local 底下：
   例如安裝 rp-pppoe-2.6.tar.gz 時，則可以指定該套件需要安裝於 /usr/local/rp-pppoe 當中，如此一來，該套件會將所有的資料都寫入 /usr/local/rp-pppoe 當中，因此，未來如果要移除該套件，只要將該目錄刪除即可視為成功的移除了！


4. 加上 man path
   不過單獨安裝某個套件在某一特定路徑下的作法，會導致當有 man page 的時候，使用預設的 MANPATH 會找不到相關的說明檔案內容。這個時候就必須要將 man page 的路徑加到 /etc/man.config 檔案中了！否則使用 man 也查詢不到指令的使用方法的。以上面的例子為例，如果是安裝了 /usr/local/rp-pppoe 當中，通常 man page 會放在 /usr/local/rp-pppoe/man 當中，所以，您就必需要在 /etc/man.config 裡面差不多 40~50 行左右的地方，加入底下這一行：
   
   MANPATH /usr/local/rp-pppoe/man
   
   這樣就可以使用 man 來查詢資料囉！

讀萬卷書不如行萬里路啊！所以當然我們就來給他測試看看，看您是否真的瞭解了如何利用 Tarball 來安裝軟體呢？！我們利用時間伺服器 ntp-4.1.2 這個套件來測試安裝看看。先請到 http://www.ntp.org/downloads.html 這個目錄去下載檔案，(您也可以下載比較新的檔案來測試的啦！) 或者直接到鳥哥的網站下載：

http://linux.vbird.org/linux_basic/0520source/ntp-stable-4.2.0a-20050816.tar.gz。

假設我對這個套件的要求是這樣的：

• 假設 ntp-stable-4.2.0a-20050816.tar.gz 這個檔案放置在 /root 這個目錄下；
• 原始碼請解開在 /usr/local/src 底下；
• 我要安裝到 /usr/local/ntp 這個目錄中；

那麼您可以依照底下的步驟來安裝測試看看( 如果可以的話，請您不要參考底下的文件資料， 先自行安裝過一遍這個軟體，然後再來對照一下鳥哥的步驟喔！)。

# 1. 解壓縮，並閱讀一下 ntp 底下的 README 與 INSTALL：
[root@linux ~]# cd /usr/local/src
[root@linux src]# tar -zxvf /root/ntp-stable-4.2.0a-20050816.tar.gz
# 這個步驟會讓原始碼解開成為 /usr/local/src/ntp-stable-4.2.0a-20050816 這個目錄

# 2. 進入原始碼所在目錄，並且查閱如何安裝的技巧：
[root@linux src]# cd ntp-stable-4.2.0a-20050816
[root@linux ntp*]# vi INSTALL ( 或 vi README )

# 3. 開始設定參數、編譯與安裝：
[root@linux ntp*]# ./configure --help | more
# 上面這個動作可以察看一下可用的參數！

[root@linux ntp*]# ./configure --prefix=/usr/local/ntp \
>  --enable-all-clocks --enable-parse-clocks
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
......中間省略......
config.status: creating util/Makefile
config.status: creating config.h
config.status: executing depfiles commands
# 一般來說 configure 設定參數較重要的就是那個 --prefix=/path 了，
# --prefix 後面接的路徑就是『這個軟體未來要安裝到那個目錄去？』
# 如果您沒有指定 --prefix=/path 這個參數，通常預設參數就是 /usr/local
# 至於其他的參數意義就得要參考 ./configure --help 了！
# 這個動作完成之後會產生 makefile 或 Makefile 這個檔案
# 當然啦，這個偵測檢查的過程會顯示在螢幕上，特別留意關於 gcc 的檢查，
# 還有最重要的是最後需要成功的建立起 Makefile 才行！(上面最後一行) 

# 4. 編譯與安裝：
[root@linux ntp*]# make clean; make
[root@linux ntp*]# make check
[root@linux ntp*]# make install
# 將資料給他安裝在 /usr/local/ntp 底下

整個動作就這麼簡單，您完成了嗎？！完成之後到 /usr/local/ntp 您發現了什麼？！

我們在前言裡面介紹了為何需要進行套件的升級，這是很重要的喔！那假如我是以 Tarball 來進行某個套件的安裝，那麼是否當我要升級這個套件時，就得要下載這個套件的完整全新的 Tarball 呢？舉個例子來說，鳥哥有個討論區在 http://phorum.vbird.org 這個網址，這個討論區是以 phpBB 這個套件來架設的，而鳥哥的討論區版本為 phpbb2.0.1.tar.gz ，目前( 2005/09/30 )最新釋出的版本則是 phpbb2.0.17.tar.gz 。那我是否需要下載全新的 phpbb2.0.17.tar.gz 這個檔案來更新原本的舊程式呢？

事實上，當我們發現一些套件的漏洞，通常是某一段程式碼寫的不好所致。因此， 所謂的『更新原始碼』常常是只有更改部分檔案的小部分內容而已。 既然如此的話，那麼我們是否可以就那些被更動的檔案來進行修改就可以咯？ 也就是說，舊版本到新版本間沒有更動過的檔案就不要理他，僅將有修訂過的檔案部分來處理即可。 這有什麼好處呢？首先，沒有更動過的檔案的目標檔( object file )根本就不需要重新編譯，而且有更動過的檔案又可以利用 make 來自動 update ( 更新 )，如此一來，呵呵！我們原先的設定( makefile 檔案裡面的規則 )將不需要重新改寫或偵測！呵呵！可以節省很多寶貴的時間呢( 例如後續章節會提到的核心的編譯！)

從上面的說明當中，我們可以發現，如果可以將舊版的原始碼資料改寫成新版的版本， 那麼就能直接編譯了，而不需要將全部的新版 Tarball 重新下載一次呢！可以節省頻寬與時間說！那麼如何改寫原始碼？ 難道要我們一個檔案一個檔案去參考然後修訂嗎？當然沒有這麼沒人性！

我們在正規表示法的時候有提到一個比對兩個檔案的指令，那就是 diff ，這個指令可以將『兩個檔案之間的差異性列出來』呢！ 那我們也知道新舊版本的檔案之間，其實只有修改一些程式而已，那麼我們可以透過 diff 比對出新舊版本之間的文字差異，然後再以相關的指令來將舊版的檔案更新嗎？！呵呵！當然可以啦！那就是 patch 這個指令啦！很多的套件開發商在更新了原始碼之後，幾乎都會釋出所謂的 patch file，也就是直接將原始碼 update 而已的一個方式喔！我們底下以一個簡單的範例來說明給您瞭解喔！

假設我們有兩個檔案，分別是 expatch.old 與 expatch.new ，他們的內容是這樣的：

[root@linux ~]# vi expatch.old
echo "check your postfix's body and header drop settings"
echo "postmap -q - regexp:header_checks < header_checks"
postmap -q - regexp:header_checks < header_checks
echo "postmap -q - regexp:body_checks < body_checks"
postmap -q - regexp:body_checks < body_checks

[root@linux ~]# vi expatch.new
echo "check your postfix's body and header drop settings"
echo "postmap -q - regexp:header_checks < header_checks This's right"
postmap -q - regexp:header_checks < header_checks
echo "postmap -q - regexp:body_checks < body_checks This's right"
postmap -q - regexp:body_checks < body_checks

兩個檔案的不同點在於：

[root@linux ~]# diff expatch.old expatch.new
2c2
< echo "postmap -q - regexp:header_checks < header_checks"
---
> echo "postmap -q - regexp:header_checks < header_checks This's right"
4c4
< echo "postmap -q - regexp:body_checks < body_checks"
---
> echo "postmap -q - regexp:body_checks < body_checks This's right"

上面顯示出兩個檔案的不同點，詳細的意義請參考正規表示法那個章節的介紹。 好了，假如我以『 diff -c expatch.old expatch.new 』以及上面顯示的資訊，做成一個檔案，內容是這樣的：

[root@linux ~]# diff -Naur expatch.old expatch.new > expatch.patch
[root@linux ~]# vi expatch.patch
--- expatch.old 2005-09-30 15:47:54.000000000 +0800
+++ expatch.new 2005-09-30 15:48:06.000000000 +0800
@@ -1,5 +1,5 @@
 echo "check your postfix's body and header drop settings"
-echo "postmap -q - regexp:header_checks < header_checks"
+echo "postmap -q - regexp:header_checks < header_checks This's right"
 postmap -q - regexp:header_checks < header_checks
-echo "postmap -q - regexp:body_checks < body_checks"
+echo "postmap -q - regexp:body_checks < body_checks This's right"
 postmap -q - regexp:body_checks < body_checks

注意到，這個檔案的第一行顯示出舊版本的檔名，而第二行則為新版本的檔名與時間， 第三行以後則是兩個檔案的差異性。那麼我們將以 patch 來進行更新，將 expatch.old 更新到 expatch.new 看看。patch 的基本語法是這樣的：

patch -p數字 < patch_file

特別留意那個 -p數字，那是與 patch_file 裡面列出的檔名有關的資訊。假如在 patch_file 第一行寫的是這樣：

*** /home/guest/example/expatch.old

那麼當我下達『 patch -p0 < patch_file 』時，則更新的檔案是『 /home/guest/example/expatch.old 』，如果『 patch -p1 < patch_file』，則更新的檔案為『home/guest/example/expatch.old』，如果『patch -p4 < patch_file』則更新『expatch.old』，也就是說， -pxx 那個 xx 代表『拿掉幾個斜線(/)』的意思！這樣可以理解了嗎？！好了，那麼我要開始來更新我的 expatch.old 了，可以這樣搞定：

[root@linux ~]# patch -p0 < expatch.patch
patching file expatch.old
# 注意喔，這個時候我的工作目錄底下會存在 expatch.old 才對！
# 然後立刻察看一下，您會發覺， expatch.new 與 expatch.old 變成一模一樣的了！

很容易瞭解吧！上面三個檔案您可以在底下的網址取得：

http://linux.vbird.org/linux_basic/0520source/expatch.tgz

加油的啦！另外，如果您是以 patch 更新原始碼，那麼記得， 您可能必須要重新編譯，並且重新 install 才算成功更新喔！並不是 patch 就好了！因為 patch 的功能主要僅只是更新原始碼檔案而已！切記切記！

鳥哥提問題：如果我有一個很舊版的套件，這個套件已經更新到很新的版本，例如核心，那麼我可以使用 patch file 來更新嗎？

這個問題挺有趣的，首先，您必須要確定舊版本與新版本之間『確實有釋出 patch file 』才行，以 kernel 2.2.xx 及 2.4.xx 來說，這兩者基本上的架構已經不同了，所以兩者間是無法以 patch file 來更新的。不過， 2.4.xx 與 2.4.yy 就可以更新了。不過，因為 kernel 每次推出的 patch 檔案都僅針對前一個版本而已，所以假設要由 kernel 2.4.20 升級到 2.4.26 ，就必須要使用 patch 2.4.21, 2.4.22, 2.4.23, 2.4.24, 2.4.25, 2.4.26 六個檔案來『依序更新』才行喔！當然，如果有朋友幫您比對過 2.4.20 與 2.4.26 ，那您自然就可以使用該 patch file 來直接一次更新囉！

首先我們要知道的是，函式庫的類型有哪些？依據函式庫被使用的類型而分為兩大類，分別是靜態( Static )與動態( Dynamic )函式庫兩類。底下我們來談一談這兩種類行的函式庫吧！

靜態函式庫：

• 副檔名：
  這類的函式庫通常副檔名為 libxxx.a 的類型；


• 編譯行為：
  這一類型的函式庫在被使用到程式當中的時候，都是整個函式庫的所有資料被整合到執行檔當中， 也就是說，當我們在進行編譯的動作時，這個函式庫會被加入到執行檔內，所以 利用靜態函式庫編譯成的檔案會比較大一些喔；


• 獨立執行的狀態：
  這類函式庫最大的優點，就是編譯成功的可執行檔 可以獨立執行，而不需要再向外部要求讀取函式庫的內容( 請參照動態函式庫的說明 )。


• 升級難易度：
  雖然執行檔可以獨立執行，然而當函式庫升級的時候， 由於我們的執行檔取用的是之前版本的函式庫，所以當函式庫升級後， 連執行檔也需要重新編譯過一次，才能將新的函式庫整合到執行檔當中。

　

動態函式庫：

• 副檔名：
  這類函式庫通常副檔名為 libxxx.so 的類型；


• 編譯行為：
  動態函式庫與靜態函式庫的編譯行為差異挺大的， 靜態函式庫是整個被編譯到執行檔當中，但是動態函式庫在編譯的時候，在程式裡面只有一個『 指向( Pointer )』 的位置而已。 也就是說，動態函式庫的內容並沒有被整合到執行檔當中，而是當執行檔要使用到函式庫的機制時， 程式才會去讀取函式庫來使用。由於執行檔當中僅具有指向動態函式庫所在的指標而已， 並不包含函式庫的內容，所以他的檔案會比較小一點。


• 獨立執行的狀態：
  這類型的函式庫不能被獨立執行， 因為當我們使用到函式庫的機制時，程式會去讀取函式庫，所以函式庫『 必須要存在』才行，而且，函式庫的『 所在目錄也不能改變』， 因為我們的可執行檔裡面僅有『指標』亦即當要取用該動態函式庫時，程式會主動去某個路徑下讀取， 呵呵！所以動態函式庫可不能隨意移動或刪除，會影響很多相依的程式軟體喔！


• 升級難易度：
  雖然這類型的執行檔無法獨立運作，然而由於是具有指向的功能， 所以，當函式庫升級後，執行檔根本不需要進行重新編譯的行為，因為執行檔會直接指向新的函式庫檔案( 前提是函式庫新舊版本的檔名相同喔！ )。

在目前的 Linux distribution 當中，我們比較傾向於使用動態函式庫， 因為如同上面提到的最重要的一點，就是函式庫的升級方便！由於 Linux 系統裡面的套件相依性太複雜了，如果使用太多的靜態函式庫，那麼升級某一個函式庫時， 都會對整個系統造成很大的衝擊！因為其他相依的執行檔也要同時重新編譯啊！ 這個時候動態函式庫可就有用多了，因為只要動態函式庫升級就好，其他的套件根本無須變動。

那麼這些函式庫放置在哪裡呢？絕大多數的函式庫都放置在：

• /usr/lib
• /lib

此外，Linux 系統裡面很多的函式庫其實 kernel 就提供了，那麼 kernel 的函式庫放在哪裡？呵呵！就是在 /lib/modules 裡面啦！裡面的資料可多著呢！不過要注意的是， 不同版本的核心提供的函式庫差異性是挺大的，所以 kernel 2.4.xx 版本的系統不要想將核心換成 2.6.xx 喔！ 很容易由於函式庫的不同而導致很多原本可以執行的軟體套件無法順利運作呢！ 更多的核心相關說明我們在後面會繼續的給他介紹的。

在瞭解了動態與靜態函式庫，也知道我們目前的 Linux 大多是將函式庫做成動態函式庫之後，再來要知道的就是，那有沒有辦法增加函式庫的讀取效能？！ 我們知道記憶體的存取速度是硬碟的好幾倍，所以， 如果我們將常用到的動態函式庫先載入記憶體當中( 快取, cache )，如此一來，當軟體套件要取用動態函式庫時，就不需要重從頭由硬碟裡面讀出囉！ 這樣不就可以增進動態函式庫的讀取速度？沒錯，是這樣的！這個時候就需要 ldconfig 與 /etc/ld.so.conf 的協助了。

如何將動態函式庫載入快取記憶體( cache )當中呢？

1. 首先，我們必須要在 /etc/ld.so.conf 裡面寫下『 想要讀入快取記憶體當中的動態函式庫所在的目錄』，注意喔， 是目錄而不是檔案；
2. 接下來則是利用 ldconfig 這個執行檔將 /etc/ld.so.conf 的資料讀入快取當中；
3. 同時也將資料記錄一份在 /etc/ld.so.cache 這個檔案當中吶！

事實上， ldconfig 還可以用來判斷動態函式庫的連結資訊呢！趕緊利用 Fedora Core 4 來測試看看。假設我還想要將我的 MySQL 函式庫加入到快取當中：

[root@linux ~]# ldconfig [-f conf] [ -C cache] [-p]
參數：
-f conf ：那個 conf 指的是某個檔案名稱，也就是說，使用 conf 作為 libarary 
	  函式庫的取得路徑，而不以 /etc/ld.so.conf 為預設值
-C cache：那個 cache 指的是某個檔案名稱，也就是說，使用 cache 作為快取暫存
	  的函式庫資料，而不以 /etc/ld.so.cache 為預設值
-p	：列出目前有的所有函式庫資料內容（在 /etc/ld.so.cache 內的資料！）
範例：

範例一：假設我的 MySQL 資料庫函式庫在 /usr/lib/mysql 當中，如何讀入 cache ？
[root@linux ~]# vi /etc/ld.so.conf
include ld.so.conf.d/*.conf
/usr/lib/mysql   <==這一行新增的啦！

[root@linux ~]# ldconfig
# 畫面上不會顯示任何的資訊，不要太緊張！正常的！

[root@linux ~]# ldconfig -p
928 libs found in cache `/etc/ld.so.cache'
        libz.so.1 (libc6) => /usr/lib/libz.so.1
        libz.so (libc6) => /usr/lib/libz.so
......中間省略......

透過上面的動作，我們可以將 MySQL 的相關函式庫給他讀入快取當中， 這樣可以加快函式庫讀取的效率呢！在某些時候，您可能會自行加入某些 Tarball 安裝的動態函式庫，而您想要讓這些動態函式庫的相關連結可以被讀入到快取當中， 這個時候您可以將動態函式庫所在的目錄名稱寫入 /etc/ld.so.conf 當中，然後執行 ldconfig 就可以啦！

說了這麼多，那麼我如何判斷某個可執行的 binary 檔案含有什麼動態函式庫呢？很簡單，利用 ldd 就可以曉得了！例如我想要知道 /usr/bin/passwd 這個程式含有的動態函式庫有哪些，可以這樣做：

[root@linux ~]# ldd [-vdr] [filename]
參數：
-v ：列出所有內容資訊；
-d ：重新將資料有遺失的 link 點秀出來！
-r ：將 ELF 有關的錯誤內容秀出來！
範例：

範例一：找出 /usr/bin/passwd 這個檔案的函式庫資料
[root@linux ~]# ldd /usr/bin/passwd
        linux-gate.so.1 =>  (0x00d19000)
	.......中間省略......
        libpam_misc.so.0 => /lib/libpam_misc.so.0 (0x00bd6000)
	.......中間省略......
# 我們前言的部分不是一直提到 passwd 有使用到 pam 的模組嗎？！怎麼知道？
# 利用 ldd 察看一下這個檔案，看到 libpam.so 了吧？這就是 pam 提供的函式庫

範例二：找出 /lib/libc.so.6 這個函式的相關其他函式庫！
[root@linux ~]# ldd /lib/libc.so.6
        /lib/ld-linux.so.2 (0x00bf1000)
        linux-gate.so.1 =>  (0x00632000)

[root@linux ~]# ldd -v /lib/libc.so.6
        /lib/ld-linux.so.2 (0x00bf1000)
        linux-gate.so.1 =>  (0x00111000)

        Version information:
        /lib/libc.so.6:
                ld-linux.so.2 (GLIBC_2.1) => /lib/ld-linux.so.2
                ld-linux.so.2 (GLIBC_2.3) => /lib/ld-linux.so.2
                ld-linux.so.2 (GLIBC_PRIVATE) => /lib/ld-linux.so.2

未來如果您常常升級安裝 RPM 的套件時( 下一章節會介紹 )，應該常常會發現那個『 相依屬性』的問題吧！？沒錯！我們可以先以 ldd 來視察『相依函式庫』之間的相關性！以先取得瞭解！ 例如上面的例子中，我們檢查了 libc.so.6 這個在 /lib 當中的函式庫，結果發現他其實還跟 ld-linux.so.2 有關！所以我們就需要來瞭解一下，那個檔案到底是什麼套件的函式庫呀！？使用 -v 這個參數還可以得知該函式庫來自於哪一個套件！像上面的資料中，就可以得到該 libc.so.6 其實可以支援 GLIBC_2.1 等的版本！

我們以 Red Hat 在 2004 年發佈的一則程式臭蟲修訂程式為例：

https://rhn.redhat.com/errata/RHBA-2004-083.html

這個 grep-2.5.1-7.8.i386.rpm 的檔案他的 MD5 指紋編碼是： 『5a0c3fcfcd4c3f937644b8cd71a0cf89』，如果您下載了這個檔案，並且執行底下的指令，應該得到相同的指紋碼的：

[root@linux ~]# md5sum [-bct] filename
[root@linux ~]# md5sum [--status|--warn] --check filename
參數：
-b ：使用 binary 的讀檔方式，預設為 Windows/DOS 檔案型態的讀取方式；
-c ：檢驗 md5sum 檔案指紋；
-t ：以文字型態來讀取 md5sum 的檔案指紋。
範例：

範例一：將剛剛的檔案下載後，測試看看！
[root@linux ~]# wget \
> ftp://updates.redhat.com/9/en/os/i386/grep-2.5.1-7.8.i386.rpm
[root@linux ~]# md5sum grep-2.5.1-7.8.i386.rpm
5a0c3fcfcd4c3f937644b8cd71a0cf89  grep-2.5.1-7.8.i386.rpm
# 看！顯示的編碼是否與上面相同呢？！趕緊測試看看！

一般而言，每個系統裡面的檔案內容大概都不相同，例如你的系統中的 /etc/passwd 這個登入資訊檔與我的一定不一樣，因為我們的使用者與密碼、 Shell 及家目錄等大概都不相同，所以由 md5sum 這個檔案指紋分析程式所自行計算出來的指紋表當然就不相同囉！

好了，那麼如何使用這個東西呢？基本上，您必須要在您的 Linux 系統上為您的這些重要的檔案進行指紋資料庫的建立( 好像在做戶口調查！ )，將底下這些檔案建立資料庫：

• /etc/passwd
• /etc/shadow( 假如你不讓使用者改密碼了 )
• /etc/group
• /usr/bin/passwd
• /sbin/portmap
• /bin/login ( 這個也很容易被駭！ )
• /bin/ls
• /bin/ps
• /usr/bin/top

等等，這幾個檔案最容易被修改了！因為很多木馬程式執行的時候，還是會有所謂的『執行序, PID』為了怕被 root 追查出來，所以他們都會修改這些檢查排程的檔案，如果你可以替這些檔案建立指紋資料庫( 就是使用 md5sum 檢查一次，將該檔案指紋記錄下來，然後常常以 shell script 的方式由程式自行來檢查指紋表是否不同了！ )，那麼對於檔案系統會比較安全啦！！