granicus.if.org Git - apache/blob - docs/manual/mod/mod_so.xml.fr

   1 <?xml version="1.0" encoding="UTF-8" ?>
   2 <!DOCTYPE modulesynopsis SYSTEM "../style/modulesynopsis.dtd">
   3 <?xml-stylesheet type="text/xsl" href="../style/manual.fr.xsl"?>
   4 <!-- English Revision: 1727637 -->
   5 <!-- French translation : Lucien GENTIS -->
   6 <!-- Reviewed by : Vincent Deffontaines -->
   7
   8 <!--
   9  Licensed to the Apache Software Foundation (ASF) under one or more
  10  contributor license agreements.  See the NOTICE file distributed with
  11  this work for additional information regarding copyright ownership.
  12  The ASF licenses this file to You under the Apache License, Version 2.0
  13  (the "License"); you may not use this file except in compliance with
  14  the License.  You may obtain a copy of the License at
  15
  16      http://www.apache.org/licenses/LICENSE-2.0
  17
  18  Unless required by applicable law or agreed to in writing, software
  19  distributed under the License is distributed on an "AS IS" BASIS,
  20  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  21  See the License for the specific language governing permissions and
  22  limitations under the License.
  23 -->
  24
  25 <modulesynopsis metafile="mod_so.xml.meta">
  26
  27 <name>mod_so</name>
  28 <description>Chargement de modules ou de code exécutable au cours du
  29 démarrage ou du redémarrage du serveur</description>
  30 <status>Extension</status>
  31 <sourcefile>mod_so.c</sourcefile>
  32 <identifier>so_module</identifier>
  33 <compatibility>Sous Windows, c'est un module de base (toujours
  34 inclus)</compatibility>
  35
  36 <summary>
  37
  38     <p>Sur les systèmes d'exploitation sélectionnés, ce module peut être
  39     utilisé pour charger des modules dans le serveur HTTP Apache en cours d'exécution
  40     grâce au mécanisme des <a
  41     href="../dso.html">Dynamic Shared Object ou Objets Partagés
  42     Dynamiquement</a> (DSO), et évite ainsi de devoir effectuer une
  43     recompilation.</p>
  44
  45     <p>Sous Unix, le code chargé provient en général de fichiers objet
  46     partagés possèdant en général l'extension <code>.so</code>, alors
  47     que sous Windows, l'extension peut être soit <code>.so</code>, soit
  48     <code>.dll</code>.</p>
  49
  50     <note type="warning"><title>Avertissement</title>
  51     <p>En général, les modules compilés pour une version majeure du
  52     serveur HTTP Apache ne fonctionneront pas avec une autre (par
  53     exemple de 1.3 à 2.0 ou 2.0 à 2.2). D'une version majeure à l'autre,
  54     il y a souvent des modifications d'API qui nécessitent des
  55     modifications du module pour qu'il puisse fonctionner avec la
  56     nouvelle version.</p>
  57     </note>
  58 </summary>
  59
  60 <section id="windows"><title>Création de modules chargeables pour
  61 Windows</title>
  62
  63     <note><title>Note</title>
  64     <p>Sous Windows, où les modules chargeables possèdent en général
  65     l'extension de nom de fichier <code>.dll</code>, les modules Apache
  66     httpd se nomment <code>mod_nom-module.so</code>, tout comme sur les
  67     autres plates-formes. Vous trouverez cependant encore des modules
  68     tiers, comme PHP par exemple, qui continuent d'utiliser la
  69     convention de nommage avec extension <code>.dll</code>.</p>
  70
  71     <p>Bien que <code>mod_so</code> puisse encore charger des modules
  72     possèdant un nom du style <code>ApacheModuleFoo.dll</code>,
  73     il est préférable d'utiliser la
  74     nouvelle convention de nommage ; si vous modifiez votre module
  75     chargeable pour la version 2.0, veuillez aussi modifier son nom pour
  76     respecter cette nouvelle convention.</p></note>
  77
  78     <p>Les API des modules Apache httpd sous Unix et Windows sont identiques.
  79     Alors que certains modules s'appuient sur certains
  80     aspects de l'architecture Unix non présents dans Windows, et ne
  81     fonctionneront donc pas sur cette dernière plate-forme, de nombreux
  82     modules fonctionnent sous Windows avec peu ou pas de modification
  83     par rapport à leur version Unix.</p>
  84
  85     <p>Lorsqu'un module fonctionne, il peut être ajouté au serveur de
  86     deux manières. Sous Unix, il peut être compilé dans le serveur.
  87     Comme Apache httpd pour Windows ne dispose pas du programme
  88     <code>Configure</code> propre à Apache httpd pour Unix, le fichier source
  89     du module doit être ajouté au fichier projet Apache de base, et ses
  90     symboles ajoutés au fichier <code>os\win32\modules.c</code>.</p>
  91
  92     <p>La seconde méthode consiste à compiler le module en tant que DLL,
  93     à savoir une bibliothèque partagée qui pourra être chargée dans le
  94     serveur en cours d'exécution via la directive
  95     <directive>LoadModule</directive>. Ces modules DLL
  96     peuvent être distribués et exécutés sur toute installation d'Apache
  97     httpd pour Windows, sans avoir à recompiler le serveur.</p>
  98
  99     <p>Pour créer un module DLL, il est nécessaire d'apporter une légère
 100     modification à son fichier source : l'enregistrement du module doit
 101     être exporté depuis la DLL (qui sera elle-même créée plus tard ;
 102     voir plus loin). Pour ce faire, ajoutez la macro
 103     <code>AP_MODULE_DECLARE_DATA</code> (définie dans les fichiers
 104     d'en-têtes d'Apache httpd) à la définition de l'enregistrement de votre
 105     module. Par exemple, si votre module est déclaré comme suit :</p>
 106
 107 <example>
 108     module foo_module;
 109 </example>
 110
 111     <p>Remplacez cette ligne par :</p>
 112 <example>
 113     module AP_MODULE_DECLARE_DATA foo_module;
 114 </example>
 115
 116     <p>Notez que cette macro ne sera prise en compte que sous Windows,
 117     si bien que le module poura être utilisé sans changement sous Unix,
 118     si besoin est. Alternativement, si vous êtes familier avec les
 119     fichiers <code>.DEF</code>, vous pouvez les utiliser pour exporter
 120     l'enregistrement du module.</p>
 121
 122     <p>Maintenant, nous sommes prêts à créer une DLL contenant notre
 123     module. Il va falloir pour cela la lier avec la bibliothèque
 124     d'export libhttpd.lib qui a été créée au cours de la compilation de
 125     la bibliothèque partagée libhttpd.dll. Il sera peut-être aussi
 126     nécessaire de modifier la configuration du compilateur pour
 127     s'assurer que les fichiers d'en-têtes d'Apache httpd seront correctement
 128     localisés. Vous trouverez cette bibliothèque à la racine du
 129     répertoire des modules de votre serveur. Il est souhaitable
 130     d'utiliser un fichier de module .dsp existant dans l'arborescence
 131     afin de s'assurer que l'environnement de compilation est
 132     correctement configuré, mais vous pouvez aussi comparer les options
 133     de compilation et d'édition de liens à votre fichier .dsp.</p>
 134
 135     <p>Ceci devrait créer une version DLL de votre module. Il vous
 136     suffit maintenant de l'enregistrer dans le répertoire
 137     <code>modules</code> à la racine de votre serveur, et d'utiliser la
 138     directive <directive>LoadModule</directive> pour la charger.</p>
 139
 140 </section>
 141
 142 <directivesynopsis>
 143 <name>LoadFile</name>
 144 <description>Liaison du fichier objet ou de la bibliothèque
 145 spécifié</description>
 146 <syntax>LoadFile <em>nom-fichier</em> [<em>nom-fichier</em>] ...</syntax>
 147 <contextlist>
 148 <context>server config</context>
 149 <context>virtual host</context>
 150 </contextlist>
 151
 152 <usage>
 153
 154     <p>La directive <directive>LoadFile</directive> permet de lier le fichier
 155     objet ou la bibliothèque spécifié au serveur lors du
 156     démarrage ou du redémarrage
 157     de ce dernier ; ceci permet d'ajouter tout code additionnel
 158     nécessaire au fonctionnement d'un module.
 159     <em>nom-fichier</em> est soit un chemin absolu, soit un chemin
 160     relatif au répertoire défini par la directive <a
 161     href="core.html#serverroot">ServerRoot</a>.</p>
 162
 163     <p>Par exemple:</p>
 164
 165     <highlight language="config">LoadFile "libexec/libxmlparse.so"</highlight>
 166
 167 </usage>
 168 </directivesynopsis>
 169
 170 <directivesynopsis>
 171 <name>LoadModule</name>
 172 <description>Liaison avec le serveur du fichier objet ou de la
 173 bibliothèque spécifié, et ajout de ce dernier à la liste des modules
 174 actifs</description>
 175 <syntax>LoadModule <em>module nom-fichier</em></syntax>
 176 <contextlist>
 177 <context>server config</context>
 178 <context>virtual host</context>
 179 </contextlist>
 180
 181 <usage>
 182     <p>La directive <directive>LoadModule</directive> permet de lier le fichier objet ou la
 183     bibliothèque <em>nom-fichier</em> avec le serveur, et d'ajouter la
 184     structure de module nommée <em>module</em> à la liste des modules
 185     actifs. <em>module</em> est le nom de la variable externe de type
 186     <code>module</code> dans le fichier, et est référencé comme <a
 187     href="module-dict.html#ModuleIdentifier">Identificateur de
 188     module</a> dans la documentation des modules.</p>
 189
 190     <p>Par exemple :</p>
 191
 192     <highlight language="config">
 193       LoadModule "status_module modules/mod_status.so"
 194     </highlight>
 195
 196     <p>charge le module spécifié depuis le sous-répertoire des modules
 197     situé à la racine du serveur.</p>
 198 </usage>
 199
 200 </directivesynopsis>
 201 </modulesynopsis>
 202