2 <!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
3 <?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
4 <!-- French translation : Lucien GENTIS -->
5 <!-- Reviewed by : Vincent Deffontaines -->
6 <!-- English Revision : 1199481 -->
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
16 http://www.apache.org/licenses/LICENSE-2.0
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.
25 <manualpage metafile="dso.xml.meta">
27 <title>Support des objets dynamiques partagés (DSO)</title>
30 <p>La conception modulaire du serveur HTTP Apache permet à l'administrateur
31 de choisir les fonctionnalités à inclure dans le serveur en sélectionnant
32 un certain nombre de modules. Les modules seront compilés en tant
33 qu'Objets Dynamiques Partagés (Dynamic Shared Objects ou DSOs)
34 qui mènent une existence séparée du fichier binaire principal
35 <program>httpd</program>. Les modules DSO peuvent être compilés en
36 même temps que le serveur, ou compilés et ajoutés ultérieurement via
37 l'Outil des Extensions à Apache (Apache Extension Tool ou
38 <program>apxs</program>).</p>
39 <p>Les modules peuvent aussi être intégrés statiquement dans le
40 binaire <program>httpd</program> lors de la compilation de ce
43 <p>Ce document décrit l'utilisation des modules DSO ainsi que les dessous
44 de leur fonctionnement.</p>
48 <section id="implementation"><title>Implémentation</title>
52 <module>mod_so</module>
55 <directive module="mod_so">LoadModule</directive>
59 <p>Le support DSO pour le chargement de modules individuels d'Apache
61 assuré par un module nommé <module>mod_so</module> qui doit être compilé
62 statiquement dans le coeur d'Apache httpd. Il s'agit du seul module avec le
63 module <module>core</module> à ne pas pouvoir être compilé en tant que
64 module DSO lui-même. Pratiquement tous les autres modules d'Apache httpd
65 distribués seront alors compilés en tant que modules DSO. Une fois
66 compilé en tant que module DSO nommé <code>mod_foo.so</code>, un
67 module peut être chargé en mémoire au
68 démarrage ou redémarrage du serveur à l'aide de
69 la directive <directive module="mod_so">LoadModule</directive> du module
70 <module>mod_so</module>, placée
71 dans votre fichier <code>httpd.conf</code>.</p>
72 <p>La compilation en mode DSO peut être désactivée pour certains
73 modules via l'option <code>--enable-mods-static</code> du script
74 <program>configure</program>, comme expliqué dans la <a
75 href="install.html">Documentation sur l'installation</a>.</p>
77 <p>Un utilitaire permet de simplifier la création de
78 fichiers DSO pour les modules d'Apache httpd
79 (particulièrement pour les modules tiers) ; il s'agit du programme nommé
80 <program>apxs</program> (<dfn>APache
81 eXtenSion</dfn>). On peut l'utiliser pour construire des modules de type
82 DSO <em>en dehors</em> de l'arborescence des sources d'Apache httpd. L'idée est
83 simple : à l'installation du serveur HTTP Apache, la procédure <code>make install</code>
84 du script <program>configure</program> installe les fichiers d'en-têtes
85 d'Apache httpd et positionne, pour la plateforme de compilation, les drapeaux du compilateur et de
86 l'éditeur de liens à l'intérieur du programme
87 <program>apxs</program>, qui sera utilisé pour la construction de fichiers DSO.
88 Il est ainsi possible d'utiliser le programme <program>apxs</program>
89 pour compiler ses sources de modules Apache httpd sans avoir besoin de
90 l'arborescence des sources de la distribution d'Apache, et sans avoir à
91 régler les drapeaux du compilateur et de l'éditeur de liens pour le support DSO.</p>
94 <section id="usage"><title>Mode d'emploi succinct</title>
96 <p>Afin que vous puissiez vous faire une idée des fonctionnalités DSO
97 du serveur HTTP Apache 2.x, en voici un résumé court et concis :</p>
101 <p>Construire et installer un module Apache httpd <em>faisant partie de la
102 distribution</em>, par exemple <code>mod_foo.c</code>,
103 en tant que module DSO <code>mod_foo.so</code> :</p>
106 $ ./configure --prefix=/chemin/vers/installation --enable-foo<br />
112 <p>Configure le serveur HTTP Apache avec tous les modules
113 activés. Seul un jeu de modules de base sera chargé au
114 démarrage du serveur. Vous pouvez modifier ce jeu de modules
115 chargés au démarrage en activant ou désactivant les directives <directive
116 module="mod_so">LoadModule</directive> correspondantes dans le
117 fichier <code>httpd.conf</code>.</p>
120 $ ./configure --enable-mods-shared=all<br />
124 <p>L'argument <code>most</code> de l'option
125 <code>--enable-modules</code> indique que tous les modules
126 non-expérimentaux ou qui ne sont pas là à titre d'exemple seront
131 <p>Certains modules ne sont utilisés que par les développeurs et
132 ne seront pas compilés. Si vous voulez les utiliser, spécifiez
133 l'option <em>all</em>. Pour compiler tous les modules disponibles,
134 y compris les modules de développeurs, spécifiez l'option
135 <em>reallyall</em>. En outre, la directive <directive
136 module="mod_so">LoadModule</directive> peut être activée pour tous
137 les modules compilés via l'option du script configure
138 <code>--enable-load-all-modules</code>.</p>
141 $ ./configure --enable-mods-shared=reallyall --enable-load-all-modules<br />
147 Construire et installer un module Apache httpd <em>tiers</em>, par exemple
148 <code>mod_foo.c</code>, en tant que module DSO
149 <code>mod_foo.so</code> <em>en dehors</em> de l'arborescence des sources
150 d'Apache httpd à l'aide du programme <program>apxs</program> :
153 $ cd /chemin/vers/module_tiers<br />
154 $ apxs -cia mod_foo.c
159 <p>Dans tous les cas, une fois le module partagé compilé, vous devez
160 ajouter une directive <directive module="mod_so">LoadModule</directive>
161 dans le fichier <code>httpd.conf</code> pour qu'Apache httpd active le module.</p>
163 <p>Voir la <a href="programs/apxs.html">documentation sur apxs</a>
164 pour plus de détails.</p>
167 <section id="background"><title>Les dessous du fonctionnement des DSO</title>
169 <p>Les clônes modernes d'UNIX proposent un mécanisme
170 appelé édition de liens et chargement dynamiques d'
171 <em>Objets Dynamiques Partagés</em> (DSO), qui permet de construire un
172 morceau de programme dans un format spécial pour le rendre chargeable
173 à l'exécution dans l'espace d'adressage d'un programme exécutable.</p>
175 <p>Ce chargement peut s'effectuer de deux manières : automatiquement par
176 un programme système appelé <code>ld.so</code> quand un programme
177 exécutable est démarré, ou manuellement à partir du programme en cours
178 d'exécution via sa propre interface système vers le chargeur Unix à l'aide
179 des appels système <code>dlopen()/dlsym()</code>.</p>
181 <p>Dans la première méthode, les DSO sont en général appelés
182 <em>bibliothèques partagées</em> ou encore <em>bibliothèques DSO</em>, et
183 possèdent des noms du style
184 <code>libfoo.so</code> ou <code>libfoo.so.1.2</code>. Ils résident dans un
185 répertoire système (en général <code>/usr/lib</code>)
186 et le lien avec le programme exécutable est établi à la compilation en
187 ajoutant <code>-lfoo</code> à la commande de l'éditeur de liens. Les
188 références à la bibliothèque sont ainsi codées en dur dans le fichier du
189 programme exécutable de façon à ce qu'au démarrage du programme, le
190 chargeur Unix soit capable de localiser <code>libfoo.so</code> dans
191 <code>/usr/lib</code>, dans des chemins codés en dur à l'aide d'options de
192 l'éditeur de liens comme <code>-R</code> ou dans des chemins définis par la
193 variable d'environnement
194 <code>LD_LIBRARY_PATH</code>. Le chargeur peut dès lors résoudre tous les symboles
195 (jusque là non encore résolus) du DSO dans le programme exécutable.</p>
197 <p>Les symboles du programme exécutable ne sont en général pas
198 référencés par le DSO (car c'est une bibliothèque de code à usage général
199 et réutilisable),
200 et ainsi aucune résolution supplémentaire n'est nécessaire. De son côté,
201 le programme exécutable ne doit accomplir aucune action particulière
203 symboles du DSO car toutes les résolutions sont effectuées par le chargeur
204 Unix. En fait, le code permettant d'invoquer
205 <code>ld.so</code> fait partie du code de démarrage pour l'exécution qui
206 est lié dans tout programme exécutable non statiquement lié.
207 L'avantage du chargement dynamique du code d'une bibliothèque partagée est
208 évident : le code de la bibliothèque ne doit être stocké qu'une seule fois
209 dans une bibliothèque système telle que <code>libc.so</code>, ce qui permet
210 d'économiser de l'espace disque pour les autres programmes.</p>
212 <p>Dans la seconde méthode, les DSO sont en général appelés <em>objets
213 partagés</em> ou <em>fichiers DSO</em>, et peuvent être nommés avec
214 l'extension de son choix (bien que le nom conseillé soit du style
215 <code>foo.so</code>). Ces fichiers résident en général dans un répertoire
216 spécifique à un programme, et aucun lien n'est automatiquement établi avec
217 le programme exécutable dans lequel ils sont utilisés.
218 Le programme exécutable charge manuellement le DSO à l'exécution dans son
219 espace d'adressage à l'aide de l'appel système <code>dlopen()</code>.
220 A ce moment, aucune résolution de symboles du DSO n'est effectuée pour le
221 programme exécutable. Par contre le chargeur Unix
222 résoud automatiquement tout symbole du DSO (non encore résolu)
223 faisant partie de l'ensemble de symboles exporté par le programme
224 exécutable et ses bibliothèques DSO déjà chargées (et en particulier tous
225 les symboles de la bibliothèque à tout faire <code>libc.so</code>).
226 De cette façon, le DSO prend connaissance de l'ensemble de symboles du
227 programme exécutable comme s'il avait été lié statiquement avec lui
230 <p>Finalement, pour tirer profit de l'API des DSO, le programme exécutable
231 doit résoudre certains symboles du DSO à l'aide de l'appel système
232 <code>dlsym()</code> pour une utilisation ultérieure dans les tables de
233 distribution, <em>etc...</em> En d'autres termes, le programme exécutable doit
234 résoudre manuellement tous les symboles dont il a besoin pour pouvoir les
236 Avantage d'un tel mécanisme : les modules optionnels du programme n'ont pas
237 besoin d'être chargés (et ne gaspillent donc pas de ressources mémoire)
238 tant qu'il ne sont pas nécessaires au programme en question. Si nécessaire,
239 ces modules peuvent être chargés dynamiquement afin d'étendre les
240 fonctionnalités de base du programme.</p>
242 <p>Bien que ce mécanisme DSO paraisse évident, il comporte au moins une
243 étape difficile : la résolution des symboles depuis le programme exécutable
244 pour le DSO lorsqu'on utilise un DSO pour étendre les fonctionnalités d'un
245 programme (la seconde méthode). Pourquoi ? Parce que la "résolution
246 inverse" des symboles DSO à partir du jeu de symboles du programme
247 exécutable dépend de la conception de la bibliothèque (la bibliothèque n'a
248 aucune information sur le programme qui l'utilise) et n'est ni standardisée
249 ni disponible sur toutes les plateformes. En pratique, les symboles globaux
250 du programme exécutable ne sont en général pas réexportés et donc
251 indisponibles pour l'utilisation dans un DSO. Trouver une méthode pour
252 forcer l'éditeur de liens à exporter tous les symboles globaux est le
253 principal problème que l'on doit résoudre lorsqu'on utilise un DSO pour
254 étendre les fonctionnalités d'un programme au moment de son exécution.</p>
256 <p>L'approche des bibliothèques partagées est la plus courante, parce que
257 c'est dans cette optique que le mécanisme DSO a été conçu ; c'est cette
258 approche qui est ainsi
259 utilisée par pratiquement tous les types de bibliothèques que fournit le
260 système d'exploitation.</p>
264 <section id="advantages"><title>Avantages et inconvénients</title>
266 <p>Les fonctionnalités ci-dessus basées sur les DSO présentent les
267 avantages suivants :</p>
270 <li>Le paquetage du serveur est plus flexible à l'exécution car le
271 processus serveur peut être assemblé à l'exécution via la
272 directive <directive module="mod_so">LoadModule</directive> du fichier de
273 configuration <code>httpd.conf</code> plutôt que par des options du script
274 <program>configure</program> à la compilation. Par exemple,
275 on peut ainsi exécuter différentes instances du serveur
276 (standard et version SSL, version minimale et version dynamique
277 [mod_perl, mod_php], <em>etc...</em>) à partir d'une seule installation
280 <li>Le paquetage du serveur peut être facilement étendu avec des modules
281 tiers, même après l'installation. Ceci présente un gros
282 avantage pour les mainteneurs de paquetages destinés aux distributions,
283 car ils peuvent créer un paquetage Apache httpd de base, et des paquetages
284 additionnels contenant des extensions telles que PHP, mod_perl, mod_fastcgi,
287 <li>Une facilité de prototypage des modules Apache httpd, car la paire
288 DSO/<program>apxs</program> vous permet d'une part de travailler en
289 dehors de l'arborescence des sources d'Apache httpd, et d'autre part de n'avoir
290 besoin que de la commande <code>apxs -i</code>
291 suivie d'un <code>apachectl restart</code> pour introduire une nouvelle
292 version de votre module fraîchement développé dans le serveur HTTP Apache
293 en cours d'exécution.</li>
296 <p>Inconvénients des DSO :</p>
299 <li>Le serveur est environ 20 % plus lent au démarrage
300 à cause des résolutions de symboles supplémentaires que le chargeur
301 Unix doit effectuer.</li>
303 <li>Le serveur est environ 5 % plus lent à l'exécution
304 sur certaines plates-formes, car le code indépendant de la position (PIC)
305 nécessite parfois des manipulations compliquées en assembleur pour
306 l'adressage relatif qui ne sont pas toujours aussi rapides que celles
307 que permet l'adressage absolu.</li>
309 <li>Comme les modules DSO ne peuvent pas être liés avec d'autres
310 bibliothèques basées sur DSO (<code>ld -lfoo</code>) sur toutes les
312 (par exemple, les plates-formes basées sur a.out ne fournissent en
313 général pas cette fonctionnalité alors que les plates-formes basées sur
314 ELF le font), vous ne pouvez pas utiliser le mécanisme DSO pour tous les
315 types de modules. Ou en d'autres termes, les modules compilés comme
316 fichiers DSO sont contraints de n'utiliser que les symboles du coeur
317 d'Apache httpd, de la bibliothèque C
318 (<code>libc</code>) et toutes autres bibliothèques statiques ou
319 dynamiques utilisées par le coeur d'Apache httpd, ou d'archives statiques
320 (<code>libfoo.a</code>) contenant du code indépendant de la
322 Il y a deux solutions pour utiliser un autre type de code : soit le
323 coeur d'Apache httpd contient déjà lui-même une référence au code, soit vous
324 chargez le code vous-même via <code>dlopen()</code>.</li>
projects / apache / blob