Diese Seite bei php.net
The PHP manual text and comments are covered by the Creative Commons Attribution 3.0 License © the PHP Documentation Group - Impressum - mail("TO:Reinhard Neidl",...)
Diese Sektion behandelt die meistverbreiteten Fehler, die beim Kompilieren von PHP auftauchen.
Sie müssen das GNU autoconf-Paket installiert haben, damit das configure-Skript aus configure.in generiert werden kann. Führen Sie ./buildconf im Hauptverzeichnis der vom SVN-Server geladenen Quellen aus. wird das configure-Skript generiert. (Solange Sie configure nicht mit der --enable-maintainer-mode-Option aufrufen, wird das configure-Skript nicht neu erstellt, wenn die configure.in-Datei aktualisiert wird. Es sollte also darauf geachtet werden, dass das configure-Skript manuell neu generiert wird, wenn Sie feststellen, dass configure.in verändert wurde. Ein Symptom für eine solche Veränderung ist, wenn Dinge wie @VARIABLE@ im Makefile auftachen, nachdem configure oder config.status ausgeführt wurde.
Sie müssen dem configure/setup-Skript den Top-Level-Pfad des Apache-Quellbaums mitteilen. Das bedeutet, dass z.B. --with-apache=/path/to/apache anstatt --with-apache=/path/to/apache/src angegeben werden muss.
Stellen Sie sicher, dass Sie Installation gründlich gelesen haben und beachten Sie, dass sowohl flex als auch bison zum Kompilieren von PHP installiert sein müssen. Abhängig von Ihrem System müssen Sie flex und bison entweder aus einer Quelle oder einem Paket wie z.B. RPM installieren.
Es ist möglich, das configure-Skript so anzupassen, dass es nicht nur in Standard-Pfaden nach Headerdatei und Bibliotheken sucht, indem dem C-Präprozessor und -Linker zusätzliche Flags übergeben werden:
CPPFLAGS=-I/path/to/include LDFLAGS=-L/path/to/library ./configure
env CPPFLAGS=-I/path/to/include LDFLAGS=-L/path/to/library ./configure
Sie müssen Bison updaten. Die aktuellste Version findet sich unter » http://www.gnu.org/software/bison/bison.html.
Einige alte Versionen von make platzieren die kompilierten Versionen der Dateien nicht in das functions-Verzeichnis im gleichen Verzeichnis. Versuchen Sie, cp *.o functions auszuführen und danach erneut make zu starten, um zu prüfen, ob sich das Problem so lösen lässt. Sollte es dann funktionieren, empfehlen wir, Ihre Version von GNU make zu aktualisieren.
Schauen Sie sich die Link-Zeile an und stellen Sie sicher, dass alle nötigen Bibliotheken am Ende mit eingeschlossen werden. Häufig werden '-ldl' und Datenbankbibliotheken vergessen.
Haben Sie beim Linken mit Apache 1.2.x daran gedacht, die benötigten Informationen in die EXTRA_LIBS-Zeile des Konfigurationsskriptes einzufügen, und haben Sie das configure-Skript des Apache wiederholt ausgeführt? Weitere Informationen finden Sie im Installationskapitel.
Einige Leute haben berichtet, dass sie '-ldl' unmittelbar nach libphp4.a einfügen mussten, wenn sie PHP mit Apache gelinkt haben.
Folgen Sie diesen Schritten:
Bitte beachten Sie: Sie können auch das neue Apache-./configure-Skript nutzen. Weitere Informationen dazu finden sie in der Datei README.configure, die der Apache-Distribution beiliegt. Auch in der Datei INSTALL Ihrer PHP-Distribution finden sich Informationen dazu.
Das bedeutet, dass das PHP-Modul nicht aufgerufen wird. Sie sollten folgende drei Dinge überprüfen:
Die Datei libphp4.a soll gar nicht existieren, Apache wird sie selbst generieren.
Das ist eine irreführende Fehlermeldung des Apache, die in aktuellen Versionen behoben ist.
Hier sind drei Dinge zu überprüfen: Wenn Apache das apxs-Perl-Skript generiert, werden manchmal aus unerfindlichen Gründen nicht die richtigen Kompiler- und Variablen-Flags verwendet. Suchen Sie Ihr apxs-Skript (probieren Sie das Kommando which apxs); oft liegt es unter /usr/local/apache/bin/apxs oder /usr/sbin/apxs. Öffnen Sie es und überprüfen Sie es auf Zeilen, die ähnlich wie folgende aussehen:
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
Wenn während des make-Teils der Installation Probleme auftauchen, die wie folgt aussehen:
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
ist Ihr System beschädigt. Sie müssen Ihre /usr/include-Dateien reparieren, indem Sie ein glibc-devel-Paket installieren, dessen Version mit der Ihrer glibc übereinstimmt. Das hat absolut nichts mit PHP zu tun. Um sich selbst davon zu überzeugen, führen Sie folgenden einfachen Test durch:
$ cat >test.c <<X #include <sys/resource.h> X $ gcc -E test.c >/dev/null
Zuerst ist es wichtig, dass Sie sich darüber im Klaren sind, dass dies eine Warnung ist und kein Fehler. Weil dies aber oft die letzte sichtbare Ausgabe von make ist, sieht es oft wie ein Fehler aus. Natürlich bricht der Kompiler ab, falls Sie ihn so konfiguriert haben, dass er bei Warnungen abbrechen soll. Beachten Sie, dass die MySQL-Unterstützung standardmäßig aktiviert ist.
Hinweis:
Bei PHP 4.3.2 sehen Sie auch den folgenden Text nachdem das Kompilieren (make) beendet wurde:
Build complete.
(It is safe to ignore warnings about tempnam and tmpnam).
Entweder schauen Sie in die config.nice-Datei im Quellbaum Ihrer aktuellen PHP-Version nach, oder Sie führen folgendes Skript aus:
<?php phpinfo(); ?>
Stellen Sie sicher, dass PHP und die GD-Bibliothek gegen die selben Bibliotheken wie libPNG gelinkt sind.
Die Verwendung von nicht-GNU-Programmen beim Kompilieren kann Probleme verursachen. Verwenden sie GNU-Programme um sicherzustellen, dass das Kompilieren fehlerfrei klappt. Z.B. wird auf Solaris die Verwendung der SunOS-BSK-kompatiblen Version oder der Solaris-Version von sed nicht funktionieren. Verwenden Sie stattdessen die GNU- oder Sun-POSIX-(xpg4-)Version von sed. Links: » GNU sed, » GNU flex, und » GNU bison.
The configure script of PHP 5.3.0 has some test lines that use expr with the option --, my expr (version 2.0) does not except --. This causes a run of error messages from the shell like:
./configure: line 2xxx: test: =: unary operator expected
expr: syntax error
I used buildconf --force to see if it would fix this.
While it resulted in a quit different file, it still had the lines of code with expr -- in it.
@ anca-phpdoc at anca dot tv:
You can use ./configure --with-libxml-dir=/path_to_xml2-config
Re Solaris
I was able to compile PHP 5.0.4 under Solaris 2.6 but I had to use gcc to do it. The source is not compatible with the Solaris C preprocessor. I did not have to install any of the gnu utilities (like sed etc) to get it to compile. It clean compiled & linked immediately using gcc 3.3.2.
Note on PHP5 setup under RedHat 7
Sometimes php5 fails to build with the following message:
[root@www bin]# ./php5
./php5: error while loading shared libraries: unexpected reloc type 0x80
Below is the configure script used:
# PHP5 CLI build, CGI/SAPI disabled
# Created by configure
'./configure' \
'--enable-libxml' \
'--with-mysql=/path_to_mysql' \
'--with-libxml=/path_to_my_libxml' \
'--program-suffix=5' \
'--disable-cgi' \
"$@"
I used the following trick to get round this:
0. If it is not a clean installation, run 'make clean' to get rid of improperly compiled files
1. run ./configure with required options
2. edit makefile:
2.1 find any LDFLAGS or PROGRAM_LDFLAGS definition
2.2 append -lstdc++ to the end of it
3. Run 'make'
4. Run 'make install'
5. Enjoy!!!
For the configure newbies among us:
If you update or reinstall any of the libraries used to compile in a different directory than they started out, you will need to make sure that you update the config.cache file (or re-generate it) so that configure will not look in the wrong place for the information.
On Mac OS X, for example, I updated my libxml using Fink. Fink placed the files in the /sw directory. However, php was still looking for important libxml files (such as xml2-config) in the old directory (/usr/bin/xml2-config). After updating config.cache with the new value of the xml2-config path, I was able to compile correctly.
If the option --with-apsx2=/path/to/apxs seems to have absolutely no effect and if the configure script ignores the Apache 2.x support, try to shutdown your Apache server (/path/to/bin/apachectl stop) and retry.
It worked here.
I post here because I was unable to find the information on the web.
I hope it will help someone.
Let say you have 2 apache ruuning, on one you want to have disable_functions set and on the other one you don't.
In fact I have (one) solution compiling two differents php modules with differents path to php.ini
using :
--with-config-file-path=/etc/php5 (for the first one)
--with-config-file-path=/etc/php5.nonchroote (for the second one)
for the second one I do not use "make install" but just
"cp .libs/libphp5.so /usr/lib/apache/1.3/libphp5.nonchroote.so"
Then you have to change the
LoadModule php5_module /usr/lib/apache/1.3/libphp5.nonchroote.so in the second httpd.conf
My problem was actually with mod_dav (which referred me here). Since they took the time to point people here, I thought I'd go ahead and add my two cents worth and expand on the above since it obviously affects PHP as well. I am running Fedora Core 3, Apache 2.0.53, & PHP 5.03. Apache and PHP were built from source.
The first suggestion in section 13 above was close, but not exactly what I needed. jimsteele's suggestion would have worked, but you would have to do it every time you use APXS. What I did was copy these lines:
my $CFG_CFLAGS_SHLIB = '-fpic -DSHARED_MODULE';
my $CFG_LD_SHLIB = 'gcc';
my $CFG_LDFLAGS_SHLIB = q(-shared);
and pasted them in the configuration section of my apxs file. Worked like a champ.
Compiling mod_php4 port on a clean freeBSD 4.8 install for Apache2 needed FOR_APACHE2= yes manually inserted into Makefile prior to version check.
If you have customized your Apache to lie about its version number, you may need to edit configure to skip the version number check. Just /APACHE_VERSION in configure to find the instance(s) where configure checks to make sure you have the right combination of --with-apxs or --with_apxs2 and Apache 1.3 or 2.0. Assuming you're smart enough to remember which version of Apache you have, you can just delete or comment out the version check and continue to march.
Defining the right environment variables for my Apache "make" invocation allowed the correct "apxs" file to be generated for me. Your mileage may vary.
cd ../apache_1.3.22
CFLAGS_SHLIB="-fpic -DSHARED_MODULE" \
LD_SHLIB=gcc \
LDFLAGS_MOD_SHLIB="-shared" \
make
Diese Seite bei php.net