編譯問(wèn)題

本節(jié)匯集了大多數(shù)編譯時(shí)出現(xiàn)的常見錯(cuò)誤。

我用匿名 GIT 服務(wù)得到了最新版的 PHP，但是里面沒有 configure 腳本！

你必須安裝有 GNU autoconf 包，這樣才可以從 configure.in生成 configure 腳本。從 GIT 服務(wù)中得到源程序后只要在最高層的目錄中運(yùn)行 ./buildconf即可。（同時(shí)要注意，除非你用了 --enable-maintainer-mode選項(xiàng)來(lái)運(yùn)行 configure，否則即使 configure.in文件更新了，configure 腳本也不會(huì)自動(dòng)重新生成。所以當(dāng)你發(fā)現(xiàn) configure.in文件更新了時(shí)要確保手工重新生成 configure 腳本。有一個(gè)癥狀是在 configure 之后或者運(yùn)行 config.status時(shí)在 Makefile 中尋找類似 @VARIABLE@ 的東西。）

我在配置 PHP 和 Apache 一起工作時(shí)遇到了問(wèn)題。說(shuō)沒找到 httpd.h，但這個(gè)文件明明就在那里！

你需要告訴 configure/setup 腳本你的 Apache 源程序最上層的目錄位置。這意味著你需要這樣指定 --with-apache=/path/to/apache而 不是這樣 --with-apache=/path/to/apache/src。

當(dāng)運(yùn)行 PHP 配置時(shí)（ ./configure），遇到類似如下的問(wèn)題：

checking lex output file root... ./configure: lex: command not found configure: error: cannot find output from lex; giving up

請(qǐng)認(rèn)真閱讀 PHP 的 安裝說(shuō)明，并注意要編譯 PHP 需要同時(shí)安裝 flex 和 bison。根據(jù)設(shè)置的不同，可以從源代碼編譯 bison 和 flex，要么通過(guò)已編譯好的發(fā)行包，例如 RPM。

當(dāng)試圖啟動(dòng) Apache 時(shí)，得到類似如下錯(cuò)誤信息：

fatal: relocation error: file /path/to/libphp4.so: symbol ap_block_alarms: referenced symbol not found

該錯(cuò)誤通常在 Apache 的核心程序被編譯為共享用途的 DSO 庫(kù)時(shí)發(fā)生。請(qǐng)嘗試重新配置 Apache，確保至少使用了如下參數(shù)：

--enable-shared=max --enable-rule=SHARED_CORE

更多信息，請(qǐng)閱讀 Apache 頂層目錄的 INSTALL文件或者 Apache 的 ? DSO 手冊(cè)。

當(dāng)運(yùn)行 configure 時(shí)，報(bào)告說(shuō)找不到頭文件或 GD 庫(kù)或 gdbm，或其它的什么包！

可以通過(guò)指定附加的選項(xiàng)讓 configure 腳本在非標(biāo)準(zhǔn)的路徑中尋找頭文件和庫(kù)并傳遞給 C 預(yù)處理器和連接器，例如：

    CPPFLAGS=-I/path/to/include LDFLAGS=-L/path/to/library ./configure

如果用 csh 的變種作為你的登錄 shell（為什么？），那就是：

    env CPPFLAGS=-I/path/to/include LDFLAGS=-L/path/to/library ./configure

當(dāng)編譯 language-parser.tab.c文件時(shí)，報(bào)錯(cuò)說(shuō) yytname undeclared。

需要更新 Bison 的版本。最新版本在 ? http://www.gnu.org/software/bison/bison.html。

當(dāng)我運(yùn)行 make時(shí)，看上去一切正常，可當(dāng)連接最后的程序時(shí)報(bào)告說(shuō)找不到某些文件而失敗了。

一些舊版本的 make 沒有正確將 functions 目錄下編譯后的文件放到同一個(gè)目錄下。試試運(yùn)行 cp *.o functions然后再運(yùn)行 make看看有沒有什么幫助。如果成功了，那你確實(shí)需要更新到最新版的 GNU make。

當(dāng)連接 PHP 時(shí)，報(bào)告說(shuō)有一些未定義的引用。

看看連接的這一行命令，確認(rèn)所有適當(dāng)?shù)膸?kù)都包括在最后了。通常可能漏掉了“-ldl”和你包括的任何數(shù)據(jù)庫(kù)支持所需要的庫(kù)。

一些人也報(bào)告說(shuō)在和 Apache 連接時(shí)他們不得不緊接著 libphp4.a之后加上“-ldl”。

我不知道怎樣把 PHP 和 Apache 1.3 一起編譯。

這其實(shí)很簡(jiǎn)單。小心地照著以下步驟來(lái)：

• 從 ? http://httpd.apache.org/download.cgi下載最新版的 Apache 1.3。
• 解壓縮到某處，例如 /usr/local/src/apache-1.3。
• 編譯 PHP，先運(yùn)行 ./configure --with-apache=/<path>/apache-1.3（用你 apache-1.3 所在的真實(shí)路徑替換掉 <path>。）
• 輸入 make接著是 make install來(lái)編譯 PHP 并把必要的文件拷貝到 Apache 的源程序目錄樹中。
• 改變當(dāng)前目錄到 /<path>/apache-1.3/src目錄并編輯 Configuration文件。添加這一行： AddModule modules/php4/libphp4.a。
• 輸入 ./configure接著是 make。
• 你現(xiàn)在應(yīng)該有一個(gè)包括 PHP 支持的 httpd 可執(zhí)行程序了！

注意：也可以用新的 Apache ./configure腳本。參見 Apache 發(fā)行包中 README.configure文件中的說(shuō)明。也看看 PHP 發(fā)行包中的 INSTALL文件。

我按照所有的步驟在 UNIX 下安裝了PHP 的 Apache 模塊版本，但我的 PHP 腳本被顯示在瀏覽器中或者提示保存此文件。

這說(shuō)明 PHP 模塊出于某些原因沒有被調(diào)用。在尋求更多幫助前先檢查三件事：

• 確認(rèn)你運(yùn)行的 httpd 程序就是你剛剛編譯的新 httpd 程序。運(yùn)行： /path/to/binary/httpd -l 如果你沒看到 mod_php4.c被列出來(lái)那你就沒有運(yùn)行對(duì)程序。找到并正確安裝程序。
• 確認(rèn)你在 Apache .conf文件中加入了正確的 Mime 類型。應(yīng)該是： AddType application/x-httpd-php .php 也確認(rèn) AddType 這一行沒有隱藏在 <Virtualhost> 或者 <Directory> 塊中，這可能會(huì)造成你的測(cè)試腳本所在位置沒有被應(yīng)用到此設(shè)置。
• 最后，Apache 1.2 和 Apache 1.3 之間默認(rèn)配置文件的位置改變了。你要確認(rèn)你添加 AddType 行的文件就是實(shí)際上用的。你可以在你的 httpd.conf 中添加一個(gè)明顯的語(yǔ)法錯(cuò)誤或者其它明顯修改，這可以告訴你是否讀取了正確的文件。

說(shuō)要用： --activate-module=src/modules/php4/libphp4.a，但是此文件根本不存在，于是我改成了 --activate-module=src/modules/php4/libmodphp4.a，結(jié)果不行。怎么回事？

注意 libphp4.a文件本來(lái)就不該存在，apache 進(jìn)程將創(chuàng)建它！

當(dāng)我用 --activate-module=src/modules/php4/libphp4.a試著把 PHP 編譯成 Apache 的靜態(tài)模塊時(shí)，報(bào)告說(shuō)我的編譯器不服從 ANSI 標(biāo)準(zhǔn)。

這是一個(gè) Apache 誤報(bào)的錯(cuò)誤信息，在新的版本中已經(jīng)修正了。

當(dāng)我用 --with-apxs編譯 PHP 時(shí)得到奇怪的錯(cuò)誤信息。

這里要檢查三件事。首先，出于某些原因當(dāng) Apache 生成 apxs Perl 腳本時(shí)，有時(shí)沒有正確的編譯和標(biāo)記變量就結(jié)束了。找到你的 apxs 腳本（用命令 which apxs），有時(shí)會(huì)在 /usr/local/apache/bin/apxs或者 /usr/sbin/apxs。打開并檢查類似如下的行：

my $CFG_CFLAGS_SHLIB  = ' ';          # substituted via Makefile.tmpl
my $CFG_LD_SHLIB      = ' ';          # substituted via Makefile.tmpl
my $CFG_LDFLAGS_SHLIB = ' ';          # substituted via Makefile.tmpl

如果你看到這幾行，那問(wèn)題就在這里。它們可能包含了僅僅空格或者其它不正確的值，例如“q()”。改成這樣：

my $CFG_CFLAGS_SHLIB  = '-fpic -DSHARED_MODULE'; # substituted via Makefile.tmpl
my $CFG_LD_SHLIB      = 'gcc';                   # substituted via Makefile.tmpl
my $CFG_LDFLAGS_SHLIB = q(-shared);              # substituted via Makefile.tmpl

第二個(gè)可能的問(wèn)題僅可能在在 Red Hat 6.1 和 6.2 中發(fā)生。Red Hat 發(fā)行的 apxs 腳本壞了。查找這一行：

my $CFG_LIBEXECDIR    = 'modules';         # substituted via APACI install

如果你看到上面這一行，改成這樣：

my $CFG_LIBEXECDIR    = '/usr/lib/apache'; # substituted via APACI install

最后，如果你重新配置或者重裝了 Apache，在 ./configure之后和 make之前增加一個(gè) make clean命令。

在 make的過(guò)程中，在 microtime 中出錯(cuò)，還有很多 RUSAGE_之類的東西。

如果 make時(shí)遇到類似這樣的問(wèn)題：

microtime.c: In function `php_if_getrusage':
microtime.c:94: storage size of `usg' isn't known
microtime.c:97: `RUSAGE_SELF' undeclared (first use in this function)
microtime.c:97: (Each undeclared identifier is reported only once
microtime.c:97: for each function it appears in.)
microtime.c:103: `RUSAGE_CHILDREN' undeclared (first use in this function)
make[3]: *** [microtime.lo] Error 1
make[3]: Leaving directory `/home/master/php-4.0.1/ext/standard'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/master/php-4.0.1/ext/standard'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/master/php-4.0.1/ext'
make: *** [all-recursive] Error 1

你的系統(tǒng)壞了。你需要安裝一個(gè)符合你的 glibc 的 glibc-devel 包來(lái)修復(fù) /usr/include中的文件。這和 PHP 絕對(duì)沒有任何關(guān)系。要證實(shí)這一點(diǎn)，試試這個(gè)簡(jiǎn)單的測(cè)試：

$ cat >test.c <<X
#include <sys/resource.h>
X
$ gcc -E test.c >/dev/null

如果出現(xiàn)錯(cuò)誤，那你就知道頭文件壞了。

當(dāng)帶 MySQL 編譯 PHP 時(shí)，可以正確地運(yùn)行configure，但是在 make的過(guò)程中出現(xiàn)了類似以下的錯(cuò)誤信息： ext/mysql/ libmysqlclient /my_tempnam.o(.text+0x46): In function my_tempnam': /php4/ext/mysql/ libmysqlclient /my_tempnam.c:103: the use of tempnam' is dangerous, better use mkstemp'，這是怎么回事

首先，我們需要認(rèn)識(shí)到這只是個(gè) 警告，而非致命錯(cuò)誤。由于這條信息通常是在 make的最后輸出的，所以看起來(lái)它可能像是一個(gè)致命錯(cuò)誤，但實(shí)際上不是。當(dāng)然，如果將編譯器設(shè)置成遇見警告信息時(shí)停止，則這也可以算是致命錯(cuò)誤。另外值得一提的是，MySQL 的支持是默認(rèn)打開的。

注意:

自 PHP 4.3.2 起，你將在編譯（make）結(jié)束后看到下面的文字：

Build complete.
(It is safe to ignore warnings about tempnam and tmpnam).

我想升級(jí)我的 PHP。上哪里找到我用來(lái)配置目前的 PHP 的 ./configure的參數(shù)呢？

要么在你用來(lái)編譯當(dāng)前的 PHP 的源碼樹中查看 config.nice 文件，如果沒有，只要運(yùn)行此腳本：

<?php phpinfo(); ?>

在輸出的頂端顯示了用來(lái)配置此 PHP 的 ./configure參數(shù)。

和 GD 庫(kù)一起編譯 PHP 時(shí)，要么給出一個(gè)奇怪的編譯錯(cuò)誤，要么在運(yùn)行時(shí)出現(xiàn) segfaults。

確保你的 GD 庫(kù)和 PHP 在連接時(shí)使用了用同樣的支持庫(kù)（例如 libpng）。

當(dāng)編譯 PHP 時(shí)我看到一些隨機(jī)的錯(cuò)誤，好像死了。我用的是 Solaris，不知道有沒有關(guān)系。

當(dāng)編譯 PHP 時(shí)使用非 GNU 的工具會(huì)導(dǎo)致問(wèn)題。確保使用 GNU 工具來(lái)確保能夠正確編譯 PHP。例如，在 Solaris 下面不論使用 SunOS BSD 兼容或者 Solaris 版本的 sed都不行，但是使用 GNU 或者 Sun POSIX (xpg4) 版本的 sed就可以。相關(guān)連接： ? GNU sed， ? GNU flex， ? GNU bison。