本节汇集了大多数编译时出现的常见错误。
你必须安装有 GNU autoconf 包,这样才可以从
configure.in生成 configure 脚本。从 GIT 服务中得到源程序后只要在最高层的目录中运行
./buildconf即可。(同时要注意,除非你用了
--enable-maintainer-mode选项来运行 configure,否则即使
configure.in文件更新了,configure 脚本也不会自动重新生成。所以当你发现
configure.in文件更新了时要确保手工重新生成 configure 脚本。有一个症状是在 configure 之后或者运行
config.status时在 Makefile 中寻找类似 @VARIABLE@ 的东西。)
你需要告诉 configure/setup 脚本你的 Apache 源程序最上层的目录位置。这意味着你需要这样指定 --with-apache=/path/to/apache而 不是这样 --with-apache=/path/to/apache/src。
./configure),遇到类似如下的问题:
请认真阅读 PHP 的 安装说明,并注意要编译 PHP 需要同时安装 flex 和 bison。根据设置的不同,可以从源代码编译 bison 和 flex,要么通过已编译好的发行包,例如 RPM。
可以通过指定附加的选项让 configure 脚本在非标准的路径中寻找头文件和库并传递给 C 预处理器和连接器,例如:
CPPFLAGS=-I/path/to/include LDFLAGS=-L/path/to/library ./configure
env CPPFLAGS=-I/path/to/include LDFLAGS=-L/path/to/library ./configure
yytname undeclared。
需要更新 Bison 的版本。最新版本在 » http://www.gnu.org/software/bison/bison.html。
一些旧版本的 make 没有正确将 functions 目录下编译后的文件放到同一个目录下。试试运行 cp *.o functions然后再运行 make看看有没有什么帮助。如果成功了,那你确实需要更新到最新版的 GNU make。
看看连接的这一行命令,确认所有适当的库都包括在最后了。通常可能漏掉了“-ldl”和你包括的任何数据库支持所需要的库。
一些人也报告说在和 Apache 连接时他们不得不紧接着 libphp4.a之后加上“-ldl”。
这说明 PHP 模块出于某些原因没有被调用。在寻求更多帮助前先检查三件事:
/path/to/binary/httpd -l
如果你没看到
mod_php4.c被列出来那你就没有运行对程序。找到并正确安装程序。
Apache .conf文件中加入了正确的 Mime 类型。应该是:
AddType application/x-httpd-php .php
也确认 AddType 这一行没有隐藏在 <Virtualhost> 或者 <Directory> 块中,这可能会造成你的测试脚本所在位置没有被应用到此设置。
--activate-module=src/modules/php4/libphp4.a,但是此文件根本不存在,于是我改成了
--activate-module=src/modules/php4/libmodphp4.a,结果不行。怎么回事?
注意 libphp4.a文件本来就不该存在,apache 进程将创建它!
--activate-module=src/modules/php4/libphp4.a试着把 PHP 编译成 Apache 的静态模块时,报告说我的编译器不服从 ANSI 标准。
这是一个 Apache 误报的错误信息,在新的版本中已经修正了。
这里要检查三件事。首先,出于某些原因当 Apache 生成 apxs Perl 脚本时,有时没有正确的编译和标记变量就结束了。找到你的 apxs 脚本(用命令 which apxs),有时会在 /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
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
my $CFG_LIBEXECDIR = 'modules'; # substituted via APACI install
my $CFG_LIBEXECDIR = '/usr/lib/apache'; # substituted via APACI install
RUSAGE_之类的东西。
如果 make时遇到类似这样的问题:
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
你的系统坏了。你需要安装一个符合你的 glibc 的 glibc-devel 包来修复 /usr/include 中的文件。这和 PHP 绝对没有任何关系。要证实这一点,试试这个简单的测试:
$ cat >test.c <<X #include <sys/resource.h> X $ gcc -E test.c >/dev/null
make 的过程中出现了类似以下的错误信息:
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',这是怎么回事?
首先,我们需要认识到这只是个警告,而非致命错误。由于这条信息通常是在
make 的最后输出的,所以看起来它可能像是一个致命错误,但实际上不是。当然,如果将编译器设置成遇见警告信息时停止,则这也可以算是致命错误。另外值得一提的是,MySQL
的支持是默认打开的。
注意:
自 PHP 4.3.2 起,你将在编译(make)结束后看到下面的文字:
Build complete.
(It is safe to ignore warnings about tempnam and tmpnam).
要么在你用来编译当前的 PHP 的源码树中查看 config.nice 文件,如果没有,只要运行此脚本:
<?php phpinfo(); ?>确保你的 GD 库和 PHP 在连接时使用了用同样的支持库(例如 libpng)。
当编译 PHP 时使用非 GNU 的工具会导致问题。确保使用 GNU 工具来确保能够正确编译 PHP。例如,在 Solaris 下面不论使用 SunOS BSD 兼容或者 Solaris 版本的
sed都不行,但是使用 GNU 或者 Sun POSIX (xpg4) 版本的
sed就可以。相关连接:
» GNU sed,
» GNU flex,
» GNU bison。