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.
Problèmes de compilation
Cette section couvre les erreurs les plus communes pouvant se produire lors de la compilation de PHP.
- J'ai téléchargé la dernière version des sources de PHP en utilisant Git, mais il n'y a pas de script configure !
- J'ai des problèmes pour configurer PHP avec Apache. On m'indique que httpd.h n'est pas trouvé, mais il est bien là ou je l'ai spécifié !
- Pendant la configuration de PHP (./configure), vous rencontrez une erreur semblable à celle-ci : checking lex output file root... ./configure: lex: command not found configure: error: cannot find output from lex; giving up
- Quand je lance Apache, j'obtiens le message suivant : fatal: relocation error: file /path/to/libphp4.so: symbol ap_block_alarms: referenced symbol not found
- Quand je lance le ./configure, on me dit que les fichiers d'en-tête de GD, gdbm, ... ne sont pas trouvés !
- Quand le fichier language-parser.tab.c est compilé, j'obtiens un message yytname undeclared.
- Quand je lance make, tout semble bien se passer, mais ça échoue quand il essaie de lier l'application finale, en prétendant qu'il manque des fichiers.
- Au moment de lier PHP, il y a des références indéfinies.
- Je ne vois pas comment compiler PHP avec Apache 1.3.
- J'ai suivi toutes les étapes pour installer le module Apache sous Unix, mais malgré tout, mes scripts PHP s'affichent en clair dans mon navigateur ou celui-ci me demande de sauver le fichier.
- Il est dit d'utiliser --activate-module=src/modules/php4/libphp4.a, mais ce fichier n'existe pas, alors je l'ai changé pour --activate-module=src/modules/php4/libmodphp4.a et ça ne fonctionne pas. Qu'est ce qui se passe ?
- Quand j'essaie de compiler Apache avec PHP en module statique en utilisant --activate-module=src/modules/php4/libphp4.a on me répond que mon compilateur n'est pas conforme aux normes ANSI.
- Quand j'esaie de compiler PHP avec --with-apxs, j'obtiens des messages d'erreur étranges.
- Pendant le make, j'ai des erreurs concernant microtime et beaucoup de RUSAGE_.
- Quand je compile PHP avec le support MySQL, le configure se passe bien, mais pendant le make, j'obtiens une erreur de ce style : 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', qu'est ce qui ne va pas ?
- Je veux mettre à jour mon PHP. Où puis-je trouver la ligne ./configure qui a été utilisée pour mon installation actuelle de PHP?
- Quand je compile PHP avec le support de la bibliothèque GD, j'obtiens des erreurs de compilation étrange, voire même des erreurs de segmentation.
- Quand je compile PHP, j'obtiens des erreurs aléatoires, voire même tout s'arrête. J'utilise Solaris.
- J'ai téléchargé la dernière version des sources de PHP en utilisant Git, mais il n'y a pas de script configure !
-
Vous devez avoir le logiciel GNU autoconf d'installé pour générer le script configure à partir de configure.in. Lancez juste ./buildconf à la racine du répertoire des sources après avoir récupéré celles-ci à partir du serveur Git. (De plus, à moins que vous ne lanciez configure avec l'option --enable-maintainer-mode, le script configure ne sera pas automatiquement reconstruit si configure.in est mis à jour, vous obligeant à le faire à la main quand vous remarquez que configure.in est mis à jour. Une conséquence de ceci est que l'on trouve des choses telles que @VARIABLE@ dans votre Makefile après que configure ou config.status soit lancé.)
- J'ai des problèmes pour configurer PHP avec Apache. On m'indique que httpd.h n'est pas trouvé, mais il est bien là ou je l'ai spécifié !
-
Vous devez spécifier au script de configuration (configure) l'emplacement du répertoire ou sont les sources de Apache. Cela signifie que vous devez spécifier --with-apache=/chemin/vers/apache et pas --with-apache=/chemin/vers/apache/src .
-
Pendant la configuration de PHP (./configure), vous
rencontrez une erreur semblable à celle-ci :
checking lex output file root... ./configure: lex: command not found
configure: error: cannot find output from lex; giving up
-
Assurez-vous de bien avoir lu les instructions d'installation et d'avoir flex et bison d'installés pour compiler PHP. Selon votre système, vous devrez installer bison et flex à partir de sources ou bien de paquets, tel qu'un RPM.
- Quand je lance le ./configure, on me dit que les fichiers d'en-tête de GD, gdbm, ... ne sont pas trouvés !
-
Vous pouvez forcer le script configure à chercher les fichiers d'en-tête à des endroits non-standard en passant des options supplémentaires au préprocesseur C et à l'éditeur de liens, par exemple :
Si vous utilisez une variante de csh, utilisez plutôt :CPPFLAGS=-I/path/to/include LDFLAGS=-L/path/to/library ./configureenv CPPFLAGS=-I/path/to/include LDFLAGS=-L/path/to/library ./configure
- Quand le fichier language-parser.tab.c est compilé, j'obtiens un message yytname undeclared.
-
Vous devez mettre à jour votre version de bison. Vous pourrez trouver la dernière version sur » http://www.gnu.org/software/bison/bison.html.
- Quand je lance make, tout semble bien se passer, mais ça échoue quand il essaie de lier l'application finale, en prétendant qu'il manque des fichiers.
-
Certaines anciennes versions de make ne déplacent pas correctement les versions compilées des fichiers dans le répertoire functions. Essayez de lancer cp *.o functions et de relancer make pour voir si le problème est résolu. Si tel est le cas, vous devriez vraiment mettre à jour votre version de GNU make.
- Au moment de lier PHP, il y a des références indéfinies.
-
Jetez un oeil à la ligne de lien et assurez-vous que toutes les bibliothèques nécessaires ont été incluses à la fin. Celles qui manquent probablement sont '-ldl' et les bibliothèques relatives aux bases de données dont vous voulez le support.
Des personnes nous ont rapporté qu'elle devaient ajouter '-ldl' immédiatement après libphp4.a lors de la compilation avec Apache.
- Je ne vois pas comment compiler PHP avec Apache 1.3.
-
C'est relativement simple. Suivez attentivement ces étapes :
- Téléchargez la dernière version de Apache 1.3 sur » http://httpd.apache.org/download.cgi.
- Désarchivez le tout, par exemple dans /usr/local/src/apache-1.3.
- Compilez PHP en lançant tout d'abord ./configure --with-apache=/<path>/apache-1.3 (remplacez <path> par le chemin de votre répertoire apache-1.3).
- Tapez make puis make install pour compiler PHP et copier les fichiers nécessaires dans le répertoire source Apache.
- Déplacez-vous dans votre répertoire /<path>/apache-1.3/src et éditez le fichier Configuration. Ajoutez y : AddModule modules/php4/libphp4.a.
- Tapez : ./configure puis make.
- Vous devriez alors avoir une bibliothèque httpd avec le support de PHP !
Note: Vous pouvez utiliser le nouveau script ./configure de Apache. Suivez les instructions du fichier README.configure fourni avec votre version de Apache. Lisez aussi le fichier INSTALL inclus avec les sources de PHP.
- J'ai suivi toutes les étapes pour installer le module Apache sous Unix, mais malgré tout, mes scripts PHP s'affichent en clair dans mon navigateur ou celui-ci me demande de sauver le fichier.
-
Cela signifie que le module PHP n'est pas chargé, pour une raison ou pour une autre. Avant de chercher de l'aide ailleurs, veuillez vérifier ces quelques points :
- Assurez-vous que le binaire httpd que vous exécutez est bien le nouveau binaire que vous avez compilé. Pour cela, essayez de lancer : /chemin/vers/le/binaire/httpd -l Si vous ne voyez pas mod_php4.c dans la liste, c'est que vous n'utilisez pas le bon binaire. Trouvez et installez correctement le bon binaire.
- Assurez-vous que vous avez bien ajouté le bon type Mime à un de vos fichiers Apache .conf. Ce devrait être : AddType application/x-httpd-php .php Assurez-vous aussi que cette ligne Addtype n'est pas dissimulée dans un contexte de <Virtualhost> ou <Directory> qui l'empêcherait de s'appliquer à l'emplacement de vos scripts.
- Enfin, l'emplacement par défaut des fichiers de configuration Apache a changé entre Apache 1.2 et Apache 1.3. Vous devriez vérifier que les fichiers de configuration auxquels vous ajoutez la ligne Addtype sont bien ceux qui sont pris en compte. Vous pouvez introduire une erreur de syntaxe dans votre httpd.conf (ou bien tout autre changement incorrect) pour vous assurer que c'est bien ce fichier qui est pris en compte.
- Il est dit d'utiliser --activate-module=src/modules/php4/libphp4.a, mais ce fichier n'existe pas, alors je l'ai changé pour --activate-module=src/modules/php4/libmodphp4.a et ça ne fonctionne pas. Qu'est ce qui se passe ?
-
Notez que le fichier libphp4.a n'est pas supposé exister. Le processus apache le créera !
- Quand j'essaie de compiler Apache avec PHP en module statique en utilisant --activate-module=src/modules/php4/libphp4.a on me répond que mon compilateur n'est pas conforme aux normes ANSI.
-
C'est un mauvais message d'erreur de Apache qui n'apparaît plus dans des versions plus récentes.
- Quand j'esaie de compiler PHP avec --with-apxs , j'obtiens des messages d'erreur étranges.
-
Il y a trois choses à vérifier ici. Tout d'abord, quand Apache crée le script Perl apxs, il s'interrompt parfois en étant compilé sans le bon compilateur ou les bonnes options. Trouvez votre script apxs (lancez la commande which apxs), qui se trouve souvent à /usr/local/apache/bin/apxs ou bien /usr/sbin/apxs. Éditez-le et vérifiez que des lignes similaires sont présentes :
Si c'est ce que vous voyez, vous avez trouvé votre problème. Elles peuvent contenir juste des espaces ou d'autres valeurs incorrectes, comme 'q()'. Changez ces lignes pour obtenir :my $CFG_CFLAGS_SHLIB = ' '; # substituted via Makefile.tmpl my $CFG_LD_SHLIB = ' '; # substituted via Makefile.tmpl my $CFG_LDFLAGS_SHLIB = ' '; # substituted via Makefile.tmpl
Le deuxième problème potentiel est uniquement relatif aux distributions Red Hat 6.1 et 6.2. The scripts apxs de Red Hat est défectueux. Cherchez cette ligne :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
Si vous la voyez telle quelle, changez-la en :my $CFG_LIBEXECDIR = 'modules'; # substituted via APACI install
Enfin, si vous reconfigurez/réinstallez Apache, lancez un make clean entre votre ./configure et votre make.my $CFG_LIBEXECDIR = '/usr/lib/apache'; # substituted via APACI install
- Pendant le make, j'ai des erreurs concernant microtime et beaucoup de RUSAGE_.
-
Pendant le make, si vous rencontrez des problèmes identiques à celui-ci :
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
Votre système est défectueux. Vous devez corriger vos fichiers /usr/include en instalant un paquet glibc-devel qui correspond à votre version de la glibc. Cela n'a rien à voir avec PHP. Pour vous en convaincre, essayez ceci :
Si vous obtenez des erreurs, c'est que vos fichiers d'en-tête sont mauvais.$ cat >test.c <<X #include <sys/resource.h> X $ gcc -E test.c >/dev/null
- Quand je compile PHP avec le support MySQL, le configure se passe bien, mais pendant le make, j'obtiens une erreur de ce style : 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', qu'est ce qui ne va pas ?
-
Tout d'abord, il est important de savoir que ce n'est qu'un Warning et pas une erreur fatale. Comme c'est souvent la dernière erreur vu lors du make, ça a l'air d'une erreur fatale, mais ça n'en est pas une. Bien sûr, si vous demandez à votre compilateur de stopper à chaque Warning, ça en deviendra une. Notez aussi que le support de MySQL est activé par défaut.
Note:
Depuis PHP 4.3.2, vous verrez le texte suivant après la compilation (make) :
Build complete.
(It is safe to ignore warnings about tempnam and tmpnam).
- Je veux mettre à jour mon PHP. Où puis-je trouver la ligne ./configure qui a été utilisée pour mon installation actuelle de PHP?
-
Vous pouvez jetez un oeil au fichier config.nice dans votre répertoire source ou sinon simplement exécuter un script
Au début du résultat affiché figure la ligne ./configure qui fût utilisée lors de la configuration de votre PHP actuel.<?php phpinfo(); ?>
- Quand je compile PHP avec le support de la bibliothèque GD, j'obtiens des erreurs de compilation étrange, voire même des erreurs de segmentation.
-
Assurez-vous que votre bibliothèque GD et PHP sont liés aux mêmes bibliothèques (libpng, par exemple).
- Quand je compile PHP, j'obtiens des erreurs aléatoires, voire même tout s'arrête. J'utilise Solaris.
-
L'utilisation d'utilitaires non-GNU pour compiler PHP peut poser problème. Assurez-vous de bien utiliser des outils GNU pour être certain que votre compilation arrive à terme. Par exemple, sous Solaris, utiliser les version SunOS BSD-compatible ou Solaris de sed ne fonctionnera pas, mais utiliser les versions GNU ou Sun POSIX (xpg4) de sed fonctionnera. Liens : » GNU sed, » GNU flex et » GNU bison.
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.
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.
When building PHP 5.3.x for Apache 2.4.x you may get an error in the apxs query for the MPM_NAME.
This is because the apxs included in Apache 2.4.x doesn't recognize that query anymore.
To resolve this issue one should modify the PHP configure file to use the right MPM module used by Apache.
To know the used MPM you can execute this command: apachectl -t -D DUMP_MODULES | grep mpm
Then, edit the PHP configure file, search for the APXS_MPM variable and force its value to prefork, event or worker according to the value returned by the previous command.
Hope it helps.
-
Fabio
@ anca-phpdoc at anca dot tv:
You can use ./configure --with-libxml-dir=/path_to_xml2-config
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
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.
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!!!
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.
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
When you have installed PHP5 as a package from your distribution source list, such as yast or apt and want to upgrade the probably out of date PHP5 version make sure:
1. Apache-develope tools are installed so that you have APXS(2)
2. make a clean install which means:
make distclean
./configure --with-apxs2=/usr/sbin/apxs2 and other options
make && make test && make clean install
This will take a while, the make test basically tests your php installation if it passes all the bug reports, as of now about 8600.
Those thre lines will take a while longer! So dont panic, but read the output!
This should ensure, that you have .so files again (because of the APXS and that you have established a relation between the apache and php. Obviously you needed to deinstall the mod_php5 first. I would highly recommend to train this and verify that you have all the required kernel source files and compiler stuff on a virtual machine before doing that on your productive server!
