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>
     Vous devez avoir le logiciel GNU autoconf d'installé pour générer le
     script configure à partir de <filename>configure.in</filename>. Lancez
     juste <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 que vous ne lanciez <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, vous obligeant à le faire à la main quand vous remarquez
     que <filename>configure.in</filename> 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 <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à ou je l'ai spécifié !
    </para>
   </question>
   <answer>
    <para>
     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
     <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>
     Assurez-vous 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 votre système, vous
     devrez 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. Essayez de reconfigurer Apache, en
     vous assurant d'utiliser les options suivantes :
    </para>
    <para>
     <screen>
      --enable-shared=max --enable-rule=SHARED_CORE
     </screen>
    </para>
    <para>
     Pour davantage d'informations, lisez le fichier
     <filename>INSTALL</filename> à la racine de votre 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>
     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 :
     <programlisting>
<![CDATA[
    CPPFLAGS=-I/path/to/include LDFLAGS=-L/path/to/library ./configure
]]>
     </programlisting>
     Si vous utilisez une variante de csh, utilisez 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>
     Vous devez mettre à jour votre version de bison. Vous pourrez trouver la
     dernière version 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, vous devriez vraiment mettre à jour votre 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 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.
    </para>
    <para>
     Des personnes nous ont rapporté qu'elle 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, veuillez vérifier
     ces quelques points :
     <itemizedlist>
      <listitem>
       <simpara>
        Assurez-vous que le binaire httpd que vous exécutez est bien le
        nouveau binaire que vous avez compilé. Pour cela, essayez de lancer :
        <literal>/chemin/vers/le/binaire/httpd -l</literal>
       </simpara>
       <simpara>
        Si vous ne voyez pas <filename>mod_php4.c</filename> dans la liste,
        c'est que vous n'utilisez pas le bon binaire. Trouvez et installez
        correctement le bon binaire.
       </simpara>
      </listitem>
      <listitem>
       <simpara>
        Assurez-vous que vous avez bien ajouté le bon type Mime à un de vos
        fichiers <literal>Apache .conf</literal>. Ce devrait être :
        <literal>AddType application/x-httpd-php .php</literal>
       </simpara>
       <simpara>
        Assurez-vous aussi 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 de vos 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. 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.
       </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>
     Notez 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'esaie 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 votre 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 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 :
     <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. The scripts apxs de Red Hat est défectueux. Cherchez
     cette ligne :
     <programlisting>
<![CDATA[
my $CFG_LIBEXECDIR    = 'modules';         # substituted via APACI install
]]>
     </programlisting>
     Si vous la voyez telle quelle, changez-la en :
     <programlisting>
<![CDATA[
my $CFG_LIBEXECDIR    = '/usr/lib/apache'; # substituted via APACI install
]]>
     </programlisting>
     Enfin, si vous reconfigurez/réinstallez Apache, lancez un <command>make
     clean</command> entre votre <command>./configure</command> et votre
     <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 vous rencontrez des problèmes
     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>
     Votre système est défectueux. Vous devez corriger vos fichiers
     <filename>/usr/include</filename> 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 :
     <programlisting>
<![CDATA[
$ cat >test.c <<X
#include <sys/resource.h>
X
$ gcc -E test.c >/dev/null
]]>
     </programlisting>
     Si vous obtenez des erreurs, c'est que vos 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 vu lors du <literal>make</literal>, ç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.
    </para>
    <note>
     <para>
      Depuis PHP 4.3.2, vous verrez le texte suivant 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>
     Vous pouvez jetez un oeil au fichier config.nice dans votre 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 fût utilisée lors de la configuration
     de votre 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 étrange, voire même des erreurs de segmentation.
    </para>
   </question>
   <answer>
    <para>
     Assurez-vous que votre 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. 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
     <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
-->