# 4.2 動手編譯PHP # 4.2 動手編譯PHP 第一章我們曾介紹過，PHP編譯前的configure有兩個特殊的選項，打開它們對我們開發PHP擴展或者進行PHP嵌入式開發時非常有幫助。但是當我們正常使用PHP的時候，則不應該開啟這兩個選項。 ### --enable-debug 顧名思義，它的作用是激活調試模式。它將激活PHP源碼中幾個非常關鍵的函數，最典型的功能便是在每一個請求結束后給出這一次請求中內存的泄漏情況。 回顧一下第三章《內存管理》部分，php內核中的ZendMM( Zend Memory Manager)將會在每一個請求結束后強制釋放在這個請求中申請的內存。By running a series of aggressive regression tests against newly developed code, leak points can be easily spotted and plugged prior to any public release. Take a look at the following code snippet: ``` void show_value(int n) { char *message = emalloc(1024); sprintf(message, "The value of n is %d\n", n); php_printf("%s", message); } ``` 上面的代碼執行后，將會導致1024B的內存泄漏，但是在ZendMM的幫助下，在請求結束后會被PHP內核自動的釋放掉。 但是如果你開啟了--enable-debug選項，在請求結束后內核便會給出一條信息，告知我們程序猿這次請求的內存泄漏情況。 /cvs/php5/ext/sample/sample.c(33) :Freeing 0x084504B8 (1024 bytes), script=- === Total 1 memory leaks detected === 這條提示告知我們在這次請求結束后，ZendMM清理了泄漏的內存以及泄漏的內存位置。在它的幫助下，我們可以很快的定位到有問題的代碼，然后通過efree等函數修正這個bug。 其實，內存泄漏并不是我們在開發中碰到的唯一錯誤，還有很多其它的bug很難被檢測出來。有時候這些bug是致命的，但很難定位到出問題的代碼。很多時候我們忙活了大半個晚上，修改了很多文件，最后make，但是當我們運行腳本的時候卻得到下面的段錯誤。 ``` $ sapi/cli/php -r 'myext_samplefunc();' Segmentation Fault //如果中文環境，則顯示段錯誤 ``` Orz...錯誤出在哪呢？我們遍歷myext\_samplefuc的所有實現代碼也沒有發現問題，扔進gdb里也僅僅顯示幾行無關緊要的信息而已。這種情況下，enable-debug就能幫你大忙了，打開這個選項后，你編譯出來的php則會嵌入gdb或其它文件需要的所有調試信息。現在我們重新編譯這個擴展，再扔進gdb里調試，便會得到如下的信息： ``` #0 0x1234567 php_myext_find_delimiter(str=0x1234567 "foo@#(FHVN)@\x98\xE0...", strlen=3, tsrm_ls=0x1234567) p = strchr(str, ','); ``` 現在所有的問題都水落石出了，字符串變量str沒有以NULL結尾，而我們卻把它當作一個參數傳給了二進制不安全的字符串處理函數，str將會掃描str知道找到NULL為止，它的掃描肯定是越界了，然后引發了一個段錯誤。找到問題根源后，我們只要用memchr來替換strchr函數就能修復這個bug了。 ### --enable-maintainer-zts 第二個重要的參數便是激活php的線程安全機制(Thread Safe Resource Manager(TSRM)/Zend Thread Safety(ZTS))，使我們開發出的程序是線程安全的。對于TSRM的介紹大家可以參考第一章的介紹，在平時的開發中，建議打開這個選項。 ### --enable-embed 其實還有一個選項比較重要，那就是enable-embed，它主要用在你做php的嵌入式開發的場景中。平時我們把php作為apache的一個module進行編譯，得到libphp5.so，而這個選項便使php編譯后得到一個與我們設定的SAPI相對應的結果。 ## links - 4.1 [編譯前的準備](4.1.html) - 4.3 [Unix/Linux平臺下的編譯](4.3.html)