archived-doc-fr/faq/build.xml

<?xml version="1.0" encoding="utf-8"?>
<!-- $Revision$ -->
<!-- EN-Revision: b8e1b1357def73f310c9f7405035b3acc0cb1eaf Maintainer: gui Status: ready -->
<!-- Reviewed: yes -->

<chapter xml:id="faq.build" xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink">
 <title>Problèmes de compilation</title>
 <titleabbrev>Problèmes de compilation</titleabbrev>
 
 <para>
  Cette section couvre les erreurs les plus communes pouvant se produire
  lors de la compilation de PHP.
 </para>
 
 <qandaset>
  <qandaentry xml:id="faq.build.configure">
   <question>
    <para>
     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 !
    </para>
   </question>
   <answer>
    <para>
     Il faut avoir le logiciel GNU autoconf d'installé pour générer le
     script configure à partir de <filename>configure.in</filename>. Il suffit de lancer
     <command>./buildconf</command> à la racine du répertoire des sources
     après avoir récupéré celles-ci à partir du serveur Git. (De plus, à
     moins de lancer <command>configure</command> avec l'option
     <literal>--enable-maintainer-mode</literal>, le script configure ne sera
     pas automatiquement reconstruit si <filename>configure.in</filename>
     est mis à jour, obligeant à le faire à la main lorsque
     <filename>configure.in</filename> 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 <filename>config.status</filename> soit
     lancé.)
    </para>
   </answer>
  </qandaentry>
  
  <qandaentry xml:id="faq.build.configuring">
   <question>
    <para>
     J'ai des problèmes pour configurer PHP avec Apache.
     On m'indique que <filename>httpd.h</filename> n'est pas trouvé, mais il
     est bien là où je l'ai spécifié !
    </para>
   </question>
   <answer>
    <para>
     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
     <option role="configure">--with-apache=/chemin/vers/apache</option> et
     <emphasis>pas</emphasis>
     <option role="configure">--with-apache=/chemin/vers/apache/src</option>.
    </para>
   </answer>
  </qandaentry>
  
  <qandaentry xml:id="faq.build.lex">
   <question>
    <para>
     Pendant la configuration de PHP (<literal>./configure</literal>), vous
     rencontrez une erreur semblable à celle-ci :
    </para>
    <para>
     <screen>
      checking lex output file root... ./configure: lex: command not found
      configure: error: cannot find output from lex; giving up
     </screen>
    </para>
   </question>
   <answer>
    <para>
     Il faut s'assurer de bien avoir lu les <link
     linkend="install.unix">instructions</link> 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.
    </para>
   </answer>
  </qandaentry>
  
  <qandaentry xml:id="faq.build.apache-sharedcore">
   <question>
    <para>
     Quand je lance Apache, j'obtiens le message suivant :
    </para>
    <para>
     <screen>
      fatal: relocation error: file /path/to/libphp4.so:
      symbol ap_block_alarms: referenced symbol not found
     </screen>
    </para>
   </question>
   <answer>
    <para>
     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 :
    </para>
    <para>
     <screen>
      --enable-shared=max --enable-rule=SHARED_CORE
     </screen>
    </para>
    <para>
     Pour davantage d'informations, consulter le fichier
     <filename>INSTALL</filename> à la racine du répertoire source
     Apache ou bien <link xlink:href="&url.apachedso;">le manuel des bibliothèques
     DSO</link>.
    </para>
   </answer>
  </qandaentry>
  
  <qandaentry xml:id="faq.build.not-found">
   <question>
    <para>
     Quand je lance le ./configure, on me dit que les fichiers d'en-tête de
     GD, gdbm, ... ne sont pas trouvés !
    </para>
   </question>
   <answer>
    <para>
     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 :
     <programlisting>
<![CDATA[
    CPPFLAGS=-I/path/to/include LDFLAGS=-L/path/to/library ./configure
]]>
     </programlisting>
     Lors de l'utilisation d'une variante de csh, utiliser plutôt :
     <programlisting>
<![CDATA[
    env CPPFLAGS=-I/path/to/include LDFLAGS=-L/path/to/library ./configure
]]>
     </programlisting>
    </para>
   </answer>
  </qandaentry>
  
  <qandaentry xml:id="faq.build.yytname">
   <question>
    <para>
     Quand le fichier <filename>language-parser.tab.c</filename> est compilé,
     j'obtiens un message <literal>yytname undeclared</literal>.
    </para>
   </question>
   <answer>
    <para>
     Il faut mettre à jour la version de bison. La dernière version se trouve
     sur <link xlink:href="&url.bison;">&url.bison;</link>.
    </para>
   </answer>
  </qandaentry>
  
  <qandaentry xml:id="faq.build.link">
   <question>
    <para>
     Quand je lance <command>make</command>, tout semble bien se passer, mais
     ça échoue quand il essaie de lier l'application finale, en prétendant
     qu'il manque des fichiers.
    </para>
   </question>
   <answer>
    <para>
     Certaines anciennes versions de make ne déplacent pas correctement
     les versions compilées des fichiers dans le répertoire functions.
     Essayez de lancer <command>cp *.o functions</command> et de relancer
     <command>make</command> 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.
    </para>
   </answer>
  </qandaentry>
  
  <qandaentry xml:id="faq.build.undefined">
   <question>
    <para>
     Au moment de lier PHP, il y a des références indéfinies.
    </para>
   </question>
   <answer>
    <para>
     Jetez un oeil à la ligne de lien et il faut 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 vous
     voulez le support.
    </para>
    <para>
     Des personnes nous ont rapporté qu'elles devaient ajouter '-ldl'
     immédiatement après <filename>libphp4.a</filename> lors de la
     compilation avec Apache.
    </para>
   </answer>
  </qandaentry>

  <qandaentry xml:id="faq.build.not-running">
   <question>
    <para>
     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.
    </para>
   </question>
   <answer>
    <para>
     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 :
     <itemizedlist>
      <listitem>
       <simpara>
        Il faut s'assurer que le binaire httpd exécuté est bien le
        nouveau binaire compilé. Pour cela, essayer de lancer :
        <literal>/chemin/vers/le/binaire/httpd -l</literal>
       </simpara>
       <simpara>
        Si <filename>mod_php4.c</filename> 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.
       </simpara>
      </listitem>
      <listitem>
       <simpara>
        Il faut s'assurer d'avoir bien ajouté le bon type Mime à un des
        fichiers <literal>Apache .conf</literal>. Ce devrait être :
        <literal>AddType application/x-httpd-php .php</literal>
       </simpara>
       <simpara>
        Il faut aussi s'assurer que cette ligne Addtype n'est pas dissimulée dans
        un contexte de &lt;Virtualhost&gt; ou &lt;Directory&gt; qui
        l'empêcherait de s'appliquer à l'emplacement des scripts.
       </simpara>
      </listitem>
      <listitem>
       <simpara>
        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.
       </simpara>
      </listitem>
     </itemizedlist>
    </para>
   </answer>
  </qandaentry>
  
  <qandaentry xml:id="faq.build.activate-module">
   <question>
    <para>
     Il est dit d'utiliser <literal>--activate-module=src/modules/php4/libphp4.a</literal>,
     mais ce fichier n'existe pas, alors je l'ai changé pour
     <literal>--activate-module=src/modules/php4/libmodphp4.a</literal> et ça
     ne fonctionne pas. Qu'est-ce qui se passe ?
    </para>
   </question>
   <answer>
    <para>
     Il est à noter que le fichier <filename>libphp4.a</filename> n'est pas supposé
     exister. Le processus apache le créera !
    </para>
   </answer>
  </qandaentry>
  
  <qandaentry xml:id="faq.build.ansi">
   <question>
    <para>
     Quand j'essaie de compiler Apache avec PHP en module statique en
     utilisant <literal>--activate-module=src/modules/php4/libphp4.a</literal>
     on me répond que mon compilateur n'est pas conforme aux normes ANSI.
    </para>
   </question>
   <answer>
    <para>
     C'est un mauvais message d'erreur de Apache qui n'apparaît plus dans des
     versions plus récentes.
    </para>
   </answer>
  </qandaentry>
  
  <qandaentry xml:id="faq.build.apxs">
   <question>
    <para>
     Quand j'essaie de compiler PHP avec <option role="configure">--with-apxs</option>,
     j'obtiens des messages d'erreur étranges.
    </para>
   </question>
   <answer>
    <para>
     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 le script apxs (lancez la commande <command>which
     apxs</command>), qui se trouve souvent à
     <filename>/usr/local/apache/bin/apxs</filename> ou bien
     <filename>/usr/sbin/apxs</filename>.
     Éditez-le et vérifiez que des lignes similaires sont présentes :
     <programlisting>
<![CDATA[
my $CFG_CFLAGS_SHLIB  = ' ';          # substituted via Makefile.tmpl
my $CFG_LD_SHLIB      = ' ';          # substituted via Makefile.tmpl
my $CFG_LDFLAGS_SHLIB = ' ';          # substituted via Makefile.tmpl
]]>
     </programlisting>
     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()'. Changez ces lignes pour obtenir :
     <programlisting>
<![CDATA[
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
]]>
     </programlisting>
     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. Cherchez
     cette ligne :
     <programlisting>
<![CDATA[
my $CFG_LIBEXECDIR    = 'modules';         # substituted via APACI install
]]>
     </programlisting>
     Si elle apparaît telle quelle, la changer en :
     <programlisting>
<![CDATA[
my $CFG_LIBEXECDIR    = '/usr/lib/apache'; # substituted via APACI install
]]>
     </programlisting>
     Enfin, lors d'une reconfiguration/réinstallation d'Apache, lancer un <command>make
     clean</command> entre le <command>./configure</command> et le
     <command>make</command>.
    </para>
   </answer>
  </qandaentry>
  
  <qandaentry xml:id="faq.build.microtime">
   <question>
    <para>
     Pendant le <command>make</command>, j'ai des erreurs concernant
     microtime et beaucoup de <literal>RUSAGE_</literal>.
    </para>
   </question>
   <answer>
    <para>
     Pendant le <command>make</command>, si des problèmes sont rencontrés
     identiques à celui-ci :
     <programlisting>
<![CDATA[
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
]]>
     </programlisting>
    </para>
    <para>
     Le système est défectueux. Il faut corriger les fichiers
     <filename>/usr/include</filename> 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 :
     <programlisting>
<![CDATA[
$ cat >test.c <<X
#include <sys/resource.h>
X
$ gcc -E test.c >/dev/null
]]>
     </programlisting>
     Si des erreurs apparaissent, c'est que les fichiers d'en-tête sont
     mauvais.
    </para>
   </answer>
  </qandaentry>
  
  <qandaentry xml:id="faq.build.mysql.tempnam">
   <question>
    <para>
     Quand je compile PHP avec le support MySQL, le configure se passe
     bien, mais pendant le <literal>make</literal>, j'obtiens une erreur de
     ce style :
     <emphasis>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'</emphasis>,
     qu'est-ce qui ne va pas ?
    </para>
   </question>
   <answer>
    <para>
     Tout d'abord, il est important de savoir que ce n'est qu'un <literal>
     Warning</literal> et pas une erreur fatale. Comme c'est souvent la
     dernière erreur vue lors du <literal>make</literal>, ç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.
     Notez aussi que le support de MySQL est activé par défaut.
    </para>
    <note>
     <para>
      À partir de PHP 4.3.2, le texte suivant apparaît après la compilation
      (make) :
     </para>
     <para>
      <screen>
       Build complete.
       (It is safe to ignore warnings about tempnam and tmpnam).
      </screen>
     </para>
    </note>
   </answer>
  </qandaentry>
  
  <qandaentry xml:id="faq.build.upgrade">
   <question>
    <para>
     Je veux mettre à jour mon PHP. Où puis-je trouver la ligne
     <command>./configure</command> qui a été utilisée pour mon installation
     actuelle de PHP?
    </para>
   </question>
   <answer>
    <para>
     Il est possible de jeter un oeil au fichier config.nice dans le répertoire
     source ou sinon simplement exécuter un script
     <programlisting role="php">
<![CDATA[
       <?php phpinfo(); ?>
]]>
     </programlisting>
     Au début du résultat affiché figure la ligne
     <command>./configure</command> qui fut utilisée lors de la configuration
     du PHP actuel.
    </para>
   </answer>
  </qandaentry>
  
  <qandaentry xml:id="faq.build.gdlibs">
   <question>
    <para>
     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.
    </para>
   </question>
   <answer>
    <para>
     Il faut s'assurer que la bibliothèque GD et PHP sont liés aux mêmes
     bibliothèques (libpng, par exemple).
    </para>
   </answer>
  </qandaentry>
  
  <qandaentry xml:id="faq.installation.needgnu">
   <question>
    <para>
     Quand je compile PHP, j'obtiens des erreurs aléatoires, voire même
     tout s'arrête. J'utilise Solaris.
    </para>
   </question>
   <answer>
    <para>
     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
     <literal>sed</literal> ne fonctionnera pas, mais utiliser les versions
     GNU ou Sun POSIX (xpg4) de <literal>sed</literal> fonctionnera. Liens :
     <link xlink:href="&url.sed;">GNU sed</link>, <link xlink:href="&url.flex;">GNU
     flex</link> et <link xlink:href="&url.bison;">GNU bison</link>.
    </para>
   </answer>
  </qandaentry>
 </qandaset>
</chapter>

<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
indent-tabs-mode:nil
sgml-parent-document:nil
sgml-default-dtd-file:"~/.phpdoc/manual.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
vim600: syn=xml fen fdm=syntax fdl=2 si
vim: et tw=78 syn=sgml
vi: ts=1 sw=1
-->