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 !

Il faut avoir le logiciel GNU autoconf d'installé pour générer le script configure à partir de configure.in. Il suffit de lancer ./buildconf à la racine du répertoire des sources après avoir récupéré celles-ci à partir du serveur Git. (De plus, à moins de lancer configure avec l'option --enable-maintainer-mode, le script configure ne sera pas automatiquement reconstruit si configure.in est mis à jour, obligeant à le faire à la main lorsque configure.in est mis à jour. Une conséquence de ceci est que l'on trouve des choses telles que @VARIABLE@ dans le 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à où je l'ai spécifié !

Il faut spécifier au script de configuration (configure) l'emplacement du répertoire où sont les sources de Apache. Cela signifie qu'il faut spécifier --with-apache=/chemin/vers/apache et pas --with-apache=/chemin/vers/apache/src.

Pendant la configuration de PHP (./configure), une erreur semblable à celle-ci apparaît :

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

Il faut s'assurer de bien avoir lu les instructions d'installation et d'avoir flex et bison d'installés pour compiler PHP. Selon le système, il faudra installer bison et flex à partir de sources ou bien de paquets, tel qu'un RPM.

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

Cette erreur survient généralement quand quelqu'un compile le cœur Apache comme bibliothèque partagée DSO. Essayer de reconfigurer Apache, en s'assurant d'utiliser les options suivantes :

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

Pour davantage d'informations, consulter le fichier INSTALL à la racine du répertoire source Apache ou bien » le manuel des bibliothèques DSO.

Quand je lance le ./configure, on me dit que les fichiers d'en-tête de GD, gdbm, ... ne sont pas trouvés !

Il est possible de 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 :

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

Lors de l'utilisation d'une variante de csh, utiliser plutôt :

    env 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.

Il faut mettre à jour la version de bison. La dernière version se trouve 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. Essayer de lancer cp *.o functions et de relancer make pour voir si le problème est résolu. Si tel est le cas, il est recommandé de mettre à jour la version de GNU make.

Au moment de lier PHP, il y a des références indéfinies.

Jeter un oeil à la ligne de lien et s'assurer 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 le support est souhaité.

Des personnes nous ont rapporté qu'elles devaient ajouter '-ldl' immédiatement après libphp4.a lors de la compilation avec Apache.

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, il convient de vérifier ces quelques points :

• Il faut s'assurer que le binaire httpd exécuté est bien le nouveau binaire compilé. Pour cela, essayer de lancer : /chemin/vers/le/binaire/httpd -l Si mod_php4.c n'apparaît pas dans la liste, c'est que le bon binaire n'est pas utilisé. Il faut trouver et installer correctement le bon binaire.
• Il faut s'assurer d'avoir bien ajouté le bon type Mime à un des fichiers Apache .conf. Ce devrait être : AddType application/x-httpd-php .php Il faut aussi s'assurer 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 des scripts.
• Enfin, l'emplacement par défaut des fichiers de configuration Apache a changé entre Apache 1.2 et Apache 1.3. Il est recommandé de vérifier que les fichiers de configuration auxquels la ligne Addtype est ajoutée sont bien ceux qui sont pris en compte. Il est possible d'introduire une erreur de syntaxe dans le httpd.conf (ou bien tout autre changement incorrect) pour s'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 ?

Il est à noter 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'essaie 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. Trouver le script apxs (lancer la commande which apxs), qui se trouve souvent à /usr/local/apache/bin/apxs ou bien /usr/sbin/apxs. L'éditer et vérifier que des lignes similaires sont présentes :

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

Si c'est ce qui apparaît, le problème est trouvé. Elles peuvent contenir juste des espaces ou d'autres valeurs incorrectes, comme 'q()'. Changer ces lignes pour obtenir :

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

Le deuxième problème potentiel est uniquement relatif aux distributions Red Hat 6.1 et 6.2. Le script apxs de Red Hat est défectueux. Chercher cette ligne :

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

Si elle apparaît telle quelle, la changer en :

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

Enfin, lors d'une reconfiguration/réinstallation d'Apache, lancer un make clean entre le ./configure et le make.

Pendant le make, j'ai des erreurs concernant microtime et beaucoup de RUSAGE_.

Pendant le make, si des problèmes sont rencontrés 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

Le système est défectueux. Il faut corriger les fichiers /usr/include en installant un paquet glibc-devel qui correspond à la version de la glibc. Cela n'a rien à voir avec PHP. Pour s'en convaincre, essayer ceci :

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

Si des erreurs apparaissent, c'est que les fichiers d'en-tête sont mauvais.

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 vue lors du make, ça a l'air d'une erreur fatale, mais ça n'en est pas une. Bien sûr, si le compilateur est configuré pour stopper à chaque Warning, ça en deviendra une. Il est à noter que le support de MySQL est activé par défaut.

Note:

À partir de PHP 4.3.2, le texte suivant apparaît 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?

Il est possible de jeter un oeil au fichier config.nice dans le répertoire source ou sinon simplement exécuter un script

<?php phpinfo(); ?>

Au début du résultat affiché figure la ligne ./configure qui fut utilisée lors de la configuration du PHP actuel.

Quand je compile PHP avec le support de la bibliothèque GD, j'obtiens des erreurs de compilation étranges, voire même des erreurs de segmentation.

Il faut s'assurer que la 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. Il faut s'assurer de bien utiliser des outils GNU pour être certain que la compilation arrive à terme. Par exemple, sous Solaris, utiliser les versions 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.