This section gathers most common errors that occur at build time.
You have to have the GNU autoconf package installed so you can
generate the configure script from configure.in. Just run
./buildconf in the top-level directory after getting
the sources from the Git server. (Also, unless you run configure
--enable-maintainer-mode option, the
configure script will not automatically get rebuilt when the
configure.in file is updated, so you should make sure to do that
manually when you notice configure.in has changed. One symptom
of this is finding things like @VARIABLE@ in your Makefile after
configure or config.status is run.)
You need to tell the configure/setup script the location of the top-level of your Apache source tree. This means that you want to specify --with-apache=/path/to/apache and not --with-apache=/path/to/apache/src.
./configure), you come across an error similar to the following:
Be sure to read the installation instructions carefully and note that you need both flex and bison installed to compile PHP. Depending on your setup you will install bison and flex from either source or a package, such as a RPM.
You can make the configure script look for header files and libraries in non-standard locations by specifying additional flags to pass to the C preprocessor and linker, such as:
CPPFLAGS=-I/path/to/include LDFLAGS=-L/path/to/library ./configure
env CPPFLAGS=-I/path/to/include LDFLAGS=-L/path/to/library ./configure
You need to update your version of Bison. You can find the latest version at » http://www.gnu.org/software/bison/bison.html.
Take a look at the link line and make sure that all of the appropriate libraries are being included at the end. Common ones that you might have missed are '-ldl' and any libraries required for any database support you included.
Some people have also reported that they had to add '-ldl' immediately following libphp4.a when linking with Apache.
This is actually quite easy. Follow these steps carefully:
Note: You can also use the new Apache
./configure script. See the instructions in
README.configure file which is part of
your Apache distribution. Also have a look at the INSTALL
file in the PHP distribution.
This means that the PHP module is not getting invoked for some reason. Three things to check before asking for further help:
/path/to/binary/httpd -lIf you don't see mod_php4.c listed then you are not running the right binary. Find and install the correct binary.
Apache .conffiles. It should be:
AddType application/x-httpd-php .phpAlso make sure that this AddType line is not hidden away inside a <Virtualhost> or <Directory> block which would prevent it from applying to the location of your test script.
--activate-module=src/modules/php4/libphp4.a, but that file doesn't exist, so I changed it to
--activate-module=src/modules/php4/libmodphp4.aand it doesn't work!? What's going on?
Note that the libphp4.a file is not supposed to exist. The apache process will create it!
--activate-module=src/modules/php4/libphp4.ait tells me that my compiler is not ANSI compliant.
This is a misleading error message from Apache that has been fixed in more recent versions.
There are three things to check here. First, for some reason when Apache builds the apxs Perl script, it sometimes ends up getting built without the proper compiler and flags variables. Find your apxs script (try the command which apxs), it's sometimes found in /usr/local/apache/bin/apxs or /usr/sbin/apxs. Open it and check for lines similar to these:
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
During the make portion of installation, if you encounter problems that look similar to this:
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: *** [microtime.lo] Error 1 make: Leaving directory `/home/master/php-4.0.1/ext/standard' make: *** [all-recursive] Error 1 make: Leaving directory `/home/master/php-4.0.1/ext/standard' make: *** [all-recursive] Error 1 make: Leaving directory `/home/master/php-4.0.1/ext' make: *** [all-recursive] Error 1
Your system is broken. You need to fix your /usr/include files by installing a glibc-devel package that matches your glibc. This has absolutely nothing to do with PHP. To prove this to yourself, try this simple test:
$ cat >test.c <<X #include <sys/resource.h> X $ gcc -E test.c >/dev/null
makeI get an error similar to the following: 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', what's wrong?
First, it's important to realize that this is a
Warning and not a fatal error. Because this is
often the last output seen during
it may seem like a fatal error but it's not. Of course, if
you set your compiler to die on Warnings, it will. Also
keep in mind that MySQL support is enabled by default.
As of PHP 4.3.2, you'll also see the following text after the build (make) completes:
(It is safe to ignore warnings about tempnam and tmpnam).
Either you look at config.nice file, in the source tree of your current PHP installation or, if this is not available, you simply run a
<?php phpinfo(); ?>
Make sure your GD library and PHP are linked against the same depending libraries (e.g. libpng).
Using non-GNU utilities while compiling PHP may cause problems. Be
sure to use GNU tools in order to be certain that compiling PHP will
work. For example, on Solaris, using either the SunOS BSD-compatible
or Solaris versions of
sed will not work, but using
the GNU or Sun POSIX (xpg4) versions of
work. Links: » GNU sed,
» GNU flex, and
» GNU bison.