1 <?xml version="1.0" encoding="ISO-8859-1" ?>
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 : 1174747 -->
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 et chargés en tant qu'objets partagés. Vous pouvez
114 ensuite les désactiver un à un en commentant la directive <directive
115 module="mod_so">LoadModule</directive> correspondante dans le
116 fichier <code>httpd.conf</code>.</p>
119 $ ./configure --enable-mods-shared=all<br />
123 <p>L'argument <code>most</code> de l'option
124 <code>--enable-modules</code> indique que tous les modules
125 non-expérimentaux ou qui ne sont pas là à titre d'exemple seront
130 Construire et installer un module Apache httpd <em>tiers</em>, par exemple
131 <code>mod_foo.c</code>, en tant que module DSO
132 <code>mod_foo.so</code> <em>en dehors</em> de l'arborescence des sources
133 d'Apache httpd à l'aide du programme <program>apxs</program> :
136 $ cd /chemin/vers/module_tiers<br />
137 $ apxs -cia mod_foo.c
142 <p>Dans tous les cas, une fois le module partagé compilé, vous devez
143 ajouter une directive <directive module="mod_so">LoadModule</directive>
144 dans le fichier <code>httpd.conf</code> pour qu'Apache httpd active le module.</p>
146 <p>Voir la <a href="programs/apxs.html">documentation sur apxs</a>
147 pour plus de détails.</p>
150 <section id="background"><title>Les dessous du fonctionnement des DSO</title>
152 <p>Les clônes modernes d'UNIX proposent un mécanisme
153 appelé édition de liens et chargement dynamiques d'
154 <em>Objets Dynamiques Partagés</em> (DSO), qui permet de construire un
155 morceau de programme dans un format spécial pour le rendre chargeable
156 à l'exécution dans l'espace d'adressage d'un programme exécutable.</p>
158 <p>Ce chargement peut s'effectuer de deux manières : automatiquement par
159 un programme système appelé <code>ld.so</code> quand un programme
160 exécutable est démarré, ou manuellement à partir du programme en cours
161 d'exécution via sa propre interface système vers le chargeur Unix à l'aide
162 des appels système <code>dlopen()/dlsym()</code>.</p>
164 <p>Dans la première méthode, les DSO sont en général appelés
165 <em>bibliothèques partagées</em> ou encore <em>bibliothèques DSO</em>, et
166 possèdent des noms du style
167 <code>libfoo.so</code> ou <code>libfoo.so.1.2</code>. Ils résident dans un
168 répertoire système (en général <code>/usr/lib</code>)
169 et le lien avec le programme exécutable est établi à la compilation en
170 ajoutant <code>-lfoo</code> à la commande de l'éditeur de liens. Les
171 références à la bibliothèque sont ainsi codées en dur dans le fichier du
172 programme exécutable de façon à ce qu'au démarrage du programme, le
173 chargeur Unix soit capable de localiser <code>libfoo.so</code> dans
174 <code>/usr/lib</code>, dans des chemins codés en dur à l'aide d'options de
175 l'éditeur de liens comme <code>-R</code> ou dans des chemins définis par la
176 variable d'environnement
177 <code>LD_LIBRARY_PATH</code>. Le chargeur peut dès lors résoudre tous les symboles
178 (jusque là non encore résolus) du DSO dans le programme exécutable.</p>
180 <p>Les symboles du programme exécutable ne sont en général pas
181 référencés par le DSO (car c'est une bibliothèque de code à usage général
182 et réutilisable),
183 et ainsi aucune résolution supplémentaire n'est nécessaire. De son côté,
184 le programme exécutable ne doit accomplir aucune action particulière
186 symboles du DSO car toutes les résolutions sont effectuées par le chargeur
187 Unix. En fait, le code permettant d'invoquer
188 <code>ld.so</code> fait partie du code de démarrage pour l'exécution qui
189 est lié dans tout programme exécutable non statiquement lié.
190 L'avantage du chargement dynamique du code d'une bibliothèque partagée est
191 évident : le code de la bibliothèque ne doit être stocké qu'une seule fois
192 dans une bibliothèque système telle que <code>libc.so</code>, ce qui permet
193 d'économiser de l'espace disque pour les autres programmes.</p>
195 <p>Dans la seconde méthode, les DSO sont en général appelés <em>objets
196 partagés</em> ou <em>fichiers DSO</em>, et peuvent être nommés avec
197 l'extension de son choix (bien que le nom conseillé soit du style
198 <code>foo.so</code>). Ces fichiers résident en général dans un répertoire
199 spécifique à un programme, et aucun lien n'est automatiquement établi avec
200 le programme exécutable dans lequel ils sont utilisés.
201 Le programme exécutable charge manuellement le DSO à l'exécution dans son
202 espace d'adressage à l'aide de l'appel système <code>dlopen()</code>.
203 A ce moment, aucune résolution de symboles du DSO n'est effectuée pour le
204 programme exécutable. Par contre le chargeur Unix
205 résoud automatiquement tout symbole du DSO (non encore résolu)
206 faisant partie de l'ensemble de symboles exporté par le programme
207 exécutable et ses bibliothèques DSO déjà chargées (et en particulier tous
208 les symboles de la bibliothèque à tout faire <code>libc.so</code>).
209 De cette façon, le DSO prend connaissance de l'ensemble de symboles du
210 programme exécutable comme s'il avait été lié statiquement avec lui
213 <p>Finalement, pour tirer profit de l'API des DSO, le programme exécutable
214 doit résoudre certains symboles du DSO à l'aide de l'appel système
215 <code>dlsym()</code> pour une utilisation ultérieure dans les tables de
216 distribution, <em>etc...</em> En d'autres termes, le programme exécutable doit
217 résoudre manuellement tous les symboles dont il a besoin pour pouvoir les
219 Avantage d'un tel mécanisme : les modules optionnels du programme n'ont pas
220 besoin d'être chargés (et ne gaspillent donc pas de ressources mémoire)
221 tant qu'il ne sont pas nécessaires au programme en question. Si nécessaire,
222 ces modules peuvent être chargés dynamiquement afin d'étendre les
223 fonctionnalités de base du programme.</p>
225 <p>Bien que ce mécanisme DSO paraisse évident, il comporte au moins une
226 étape difficile : la résolution des symboles depuis le programme exécutable
227 pour le DSO lorsqu'on utilise un DSO pour étendre les fonctionnalités d'un
228 programme (la seconde méthode). Pourquoi ? Parce que la "résolution
229 inverse" des symboles DSO à partir du jeu de symboles du programme
230 exécutable dépend de la conception de la bibliothèque (la bibliothèque n'a
231 aucune information sur le programme qui l'utilise) et n'est ni standardisée
232 ni disponible sur toutes les plateformes. En pratique, les symboles globaux
233 du programme exécutable ne sont en général pas réexportés et donc
234 indisponibles pour l'utilisation dans un DSO. Trouver une méthode pour
235 forcer l'éditeur de liens à exporter tous les symboles globaux est le
236 principal problème que l'on doit résoudre lorsqu'on utilise un DSO pour
237 étendre les fonctionnalités d'un programme au moment de son exécution.</p>
239 <p>L'approche des bibliothèques partagées est la plus courante, parce que
240 c'est dans cette optique que le mécanisme DSO a été conçu ; c'est cette
241 approche qui est ainsi
242 utilisée par pratiquement tous les types de bibliothèques que fournit le
243 système d'exploitation.</p>
247 <section id="advantages"><title>Avantages et inconvénients</title>
249 <p>Les fonctionnalités ci-dessus basées sur les DSO présentent les
250 avantages suivants :</p>
253 <li>Le paquetage du serveur est plus flexible à l'exécution car le
254 processus serveur peut être assemblé à l'exécution via la
255 directive <directive module="mod_so">LoadModule</directive> du fichier de
256 configuration <code>httpd.conf</code> plutôt que par des options du script
257 <program>configure</program> à la compilation. Par exemple,
258 on peut ainsi exécuter différentes instances du serveur
259 (standard et version SSL, version minimale et version dynamique
260 [mod_perl, mod_php], <em>etc...</em>) à partir d'une seule installation
263 <li>Le paquetage du serveur peut être facilement étendu avec des modules
264 tiers, même après l'installation. Ceci présente un gros
265 avantage pour les mainteneurs de paquetages destinés aux distributions,
266 car ils peuvent créer un paquetage Apache httpd de base, et des paquetages
267 additionnels contenant des extensions telles que PHP, mod_perl, mod_fastcgi,
270 <li>Une facilité de prototypage des modules Apache httpd, car la paire
271 DSO/<program>apxs</program> vous permet d'une part de travailler en
272 dehors de l'arborescence des sources d'Apache httpd, et d'autre part de n'avoir
273 besoin que de la commande <code>apxs -i</code>
274 suivie d'un <code>apachectl restart</code> pour introduire une nouvelle
275 version de votre module fraîchement développé dans le serveur HTTP Apache
276 en cours d'exécution.</li>
279 <p>Inconvénients des DSO :</p>
282 <li>Le serveur est environ 20 % plus lent au démarrage
283 à cause des résolutions de symboles supplémentaires que le chargeur
284 Unix doit effectuer.</li>
286 <li>Le serveur est environ 5 % plus lent à l'exécution
287 sur certaines plates-formes, car le code indépendant de la position (PIC)
288 nécessite parfois des manipulations compliquées en assembleur pour
289 l'adressage relatif qui ne sont pas toujours aussi rapides que celles
290 que permet l'adressage absolu.</li>
292 <li>Comme les modules DSO ne peuvent pas être liés avec d'autres
293 bibliothèques basées sur DSO (<code>ld -lfoo</code>) sur toutes les
295 (par exemple, les plates-formes basées sur a.out ne fournissent en
296 général pas cette fonctionnalité alors que les plates-formes basées sur
297 ELF le font), vous ne pouvez pas utiliser le mécanisme DSO pour tous les
298 types de modules. Ou en d'autres termes, les modules compilés comme
299 fichiers DSO sont contraints de n'utiliser que les symboles du coeur
300 d'Apache httpd, de la bibliothèque C
301 (<code>libc</code>) et toutes autres bibliothèques statiques ou
302 dynamiques utilisées par le coeur d'Apache httpd, ou d'archives statiques
303 (<code>libfoo.a</code>) contenant du code indépendant de la
305 Il y a deux solutions pour utiliser un autre type de code : soit le
306 coeur d'Apache httpd contient déjà lui-même une référence au code, soit vous
307 chargez le code vous-même via <code>dlopen()</code>.</li>
projects / apache / blob