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 : 587444 -->
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 peuvent être soit intégrés
33 statiquement dans le binaire <program>httpd</program> lors de la
34 compilation du serveur, soit compilés en tant qu'objets
35 dynamiques partagés (DSOs) qui existeront indépendamment du binaire
36 principal <program>httpd</program>. Les modules DSO peuvent être compilés
37 au moment de la construction du serveur, ou bien compilés séparément,
38 à l'aide de l'utilitaire des extensions d'Apache (<program>apxs</program>),
39 et associés au serveur ultérieurement.</p>
41 <p>Ce document décrit l'utilisation des modules DSO ainsi que les dessous
42 de leur fonctionnement.</p>
46 <section id="implementation"><title>Implémentation</title>
50 <module>mod_so</module>
53 <directive module="mod_so">LoadModule</directive>
57 <p>Le support DSO pour le chargement de modules individuels d'Apache est
58 assuré par un module nommé <module>mod_so</module> qui doit être compilé
59 statiquement dans le coeur d'Apache. Il s'agit du seul module avec le
60 module <module>core</module> à ne pas pouvoir être compilé en tant que
61 module DSO lui-même. Pratiquement tous les autres modules d'Apache
62 distribués peuvent être compilés en tant que modules DSO en sélectionnant
63 pour chacun d'entre eux le mode de construction DSO à l'aide de l'option
64 <code>--enable-<em>module</em>=shared</code> du script
65 <program>configure</program>, comme décrit dans la
66 <a href="install.html">Documentation de l'installation</a>. Une fois
67 compilé en tant que module DSO, un module peut être chargé en mémoire au
68 démarrage ou redémarrage du serveur à l'aide de la commande
69 <directive module="mod_so">LoadModule</directive> du module
70 <module>mod_so</module>, placée
71 dans votre fichier <code>httpd.conf</code>.</p>
73 <p>Un nouvel utilitaire a été introduit afin de simplifier la création de
74 fichiers DSO pour les modules d'Apache
75 (particulièrement pour les modules tiers) ; il s'agit du programme nommé
76 <program>apxs</program> (<dfn>APache
77 eXtenSion</dfn>). On peut l'utiliser pour construire des modules de type
78 DSO <em>en dehors</em> de l'arborescence des sources d'Apache. L'idée est
79 simple : à l'installation d'Apache, la procédure <code>make install</code>
80 du script <program>configure</program> installe les fichiers d'en-têtes
81 d'Apache et positionne, pour la plateforme de compilation, les drapeaux du compilateur et de
82 l'éditeur de liens à l'intérieur du programme
83 <program>apxs</program>, qui sera utilisé pour la construction de fichiers DSO.
84 Il est ainsi possible d'utiliser le programme <program>apxs</program>
85 pour compiler ses sources de modules Apache sans avoir besoin de
86 l'arborescence des sources de la distribution d'Apache, et sans avoir à
87 régler les drapeaux du compilateur et de l'éditeur de liens pour le support DSO.</p>
90 <section id="usage"><title>Mode d'emploi succinct</title>
92 <p>Afin que vous puissiez vous faire une idée des fonctionnalités DSO
93 d'Apache 2.x, en voici un résumé court et concis :</p>
97 Construire et installer un module Apache <em>faisant partie de la
98 distribution</em>, par exemple <code>mod_foo.c</code>,
99 en tant que module DSO <code>mod_foo.so</code> :
102 $ ./configure --prefix=/chemin/vers/répertoire-installation
103 --enable-foo=shared<br />
109 Construire et installer un module Apache <em>tiers</em>, par exemple
110 <code>mod_foo.c</code>, en tant que module DSO <code>mod_foo.so</code> :
113 $ ./configure --add-module=<var>type_de_module</var>:
114 /chemin/vers/module_tiers/mod_foo.c \<br />
116 --enable-foo=shared<br />
123 Configurer Apache pour <em>pouvoir installer ultérieurement</em> des
124 modules partagés :
127 $ ./configure --enable-so<br />
133 Construire et installer un module Apache <em>tiers</em>, par exemple
134 <code>mod_foo.c</code>, en tant que module DSO
135 <code>mod_foo.so</code> <em>en dehors</em> de l'arborescence des sources
136 d'Apache à l'aide du programme <program>apxs</program> :
139 $ cd /chemin/vers/module_tiers<br />
140 $ apxs -c mod_foo.c<br />
141 $ apxs -i -a -n foo mod_foo.la
146 <p>Dans tous les cas, une fois le module partagé compilé, vous devez
147 ajouter une directive <directive module="mod_so">LoadModule</directive>
148 dans le fichier <code>httpd.conf</code> pour qu'Apache active le module.</p>
151 <section id="background"><title>Les dessous du fonctionnement des DSO</title>
153 <p>Les clônes modernes d'UNIX proposent un astucieux mécanisme
154 communément appelé édition de liens et chargement dynamiques d'
155 <em>Objets Dynamiques Partagés</em> (DSO), qui permet de construire un
156 morceau de programme dans un format spécial pour le rendre chargeable
157 à l'exécution dans l'espace d'adressage d'un programme exécutable.</p>
159 <p>Ce chargement peut s'effectuer de deux manières : automatiquement par
160 un programme système appelé <code>ld.so</code> quand un programme
161 exécutable est démarré, ou manuellement à partir du programme en cours
162 d'exécution via sa propre interface système vers le chargeur Unix à l'aide
163 des appels système <code>dlopen()/dlsym()</code>.</p>
165 <p>Dans la première méthode, les DSO sont en général appelés
166 <em>bibliothèques partagées</em> ou encore <em>bibliothèques DSO</em>, et
167 possèdent des noms du style
168 <code>libfoo.so</code> ou <code>libfoo.so.1.2</code>. Ils résident dans un
169 répertoire système (en général <code>/usr/lib</code>)
170 et le lien avec le programme exécutable est établi à la compilation en
171 ajoutant <code>-lfoo</code> à la commande de l'éditeur de liens. Les
172 références à la bibliothèque sont ainsi codées en dur dans le fichier du
173 programme exécutable de façon à ce qu'au démarrage du programme, le
174 chargeur Unix soit capable de localiser <code>libfoo.so</code> dans
175 <code>/usr/lib</code>, dans des chemins codés en dur à l'aide d'options de
176 l'éditeur de liens comme <code>-R</code> ou dans des chemins définis par la
177 variable d'environnement
178 <code>LD_LIBRARY_PATH</code>. Le chargeur peut dès lors résoudre tous les symboles
179 (jusque là non encore résolus) du DSO dans le programme exécutable.</p>
181 <p>Les symboles du programme exécutable ne sont en général pas
182 référencés par le DSO (car c'est une bibliothèque de code à usage général
183 et réutilisable),
184 et ainsi aucune résolution supplémentaire n'est nécessaire. De son côté,
185 le programme exécutable ne doit accomplir aucune action particulière
187 symboles du DSO car toutes les résolutions sont effectuées par le chargeur
188 Unix. En fait, le code permettant d'invoquer
189 <code>ld.so</code> fait partie du code de démarrage pour l'exécution qui
190 est lié dans tout programme exécutable non statiquement lié.
191 L'avantage du chargement dynamique du code d'une bibliothèque partagée est
192 évident : le code de la bibliothèque ne doit être stocké qu'une seule fois
193 dans une bibliothèque système telle que <code>libc.so</code>, ce qui permet
194 d'économiser de l'espace disque pour les autres programmes.</p>
196 <p>Dans la seconde méthode, les DSO sont en général appelés <em>objets
197 partagés</em> ou <em>fichiers DSO</em>, et peuvent être nommés avec
198 l'extension de son choix (bien que le nom conseillé soit du style
199 <code>foo.so</code>). Ces fichiers résident en général dans un répertoire
200 spécifique à un programme, et aucun lien n'est automatiquement établi avec
201 le programme exécutable dans lequel ils sont utilisés.
202 Le programme exécutable charge manuellement le DSO à l'exécution dans son
203 espace d'adressage à l'aide de l'appel système <code>dlopen()</code>.
204 A ce moment, aucune résolution de symboles du DSO n'est effectuée pour le
205 programme exécutable. Par contre le chargeur Unix
206 résoud automatiquement tout symbole du DSO (non encore résolu)
207 faisant partie de l'ensemble de symboles exporté par le programme
208 exécutable et ses bibliothèques DSO déjà chargées (et en particulier tous
209 les symboles de la bibliothèque à tout faire <code>libc.so</code>).
210 De cette façon, le DSO prend connaissance de l'ensemble de symboles du
211 programme exécutable comme s'il avait été lié statiquement avec lui
214 <p>Finalement, pour tirer profit de l'API des DSO, le programme exécutable
215 doit résoudre certains symboles du DSO à l'aide de l'appel système
216 <code>dlsym()</code> pour une utilisation ultérieure dans les tables de
217 distribution, <em>etc...</em> En d'autres termes, le programme exécutable doit
218 résoudre manuellement tous les symboles dont il a besoin pour pouvoir les
220 Avantage d'un tel mécanisme : les modules optionnels du programme n'ont pas
221 besoin d'être chargés (et ne gaspillent donc pas de ressources mémoire)
222 tant qu'il ne sont pas nécessaires au programme en question. Si nécessaire,
223 ces modules peuvent être chargés dynamiquement afin d'étendre les
224 fonctionnalités de base du programme.</p>
226 <p>Bien que ce mécanisme DSO paraisse évident, il comporte au moins une
227 étape difficile : la résolution des symboles depuis le programme exécutable
228 pour le DSO lorsqu'on utilise un DSO pour étendre les fonctionnalités d'un
229 programme (la seconde méthode). Pourquoi ? Parce que la "résolution
230 inverse" des symboles DSO à partir du jeu de symboles du programme
231 exécutable dépend de la conception de la bibliothèque (la bibliothèque n'a
232 aucune information sur le programme qui l'utilise) et n'est ni standardisée
233 ni disponible sur toutes les plateformes. En pratique, les symboles globaux
234 du programme exécutable ne sont en général pas réexportés et donc
235 indisponibles pour l'utilisation dans un DSO. Trouver une méthode pour
236 forcer l'éditeur de liens à exporter tous les symboles globaux est le
237 principal problème que l'on doit résoudre lorsqu'on utilise un DSO pour
238 étendre les fonctionnalités d'un programme au moment de son exécution.</p>
240 <p>L'approche des bibliothèques partagées est la plus courante, parce que
241 c'est dans cette optique que le mécanisme DSO a été conçu ; c'est cette
242 approche qui est ainsi
243 utilisée par pratiquement tous les types de bibliothèques que fournit le
244 système d'exploitation. Par contre, les objets partagés sont relativement
245 peu utilisés pour étendre les fonctionnalités d'un programme.</p>
247 <p>En 1998, seule une poignée de logiciels distribués
248 utilisaient le mécanisme DSO pour réellement étendre leurs fonctionnalités
249 au moment de l'exécution : Perl 5 (via son mécanisme XS et le module
250 DynaLoader), le serveur Netscape, <em>etc...</em> A partir de la
251 version 1.3, Apache rejoignit ce groupe, car Apache
252 présentait déjà un concept modulaire pour étendre ses fonctionnalités, et
253 utilisait en interne une approche basée sur une liste de distribution pour
254 relier des modules externes avec les fonctionnalités de base d'Apache.
255 Ainsi, Apache était vraiment prédestiné à l'utilisation des DSO pour
256 charger ses modules au moment de l'exécution.</p>
259 <section id="advantages"><title>Avantages et inconvénients</title>
261 <p>Les fonctionnalités ci-dessus basées sur les DSO présentent les
262 avantages suivants :</p>
265 <li>Le paquetage du serveur est plus flexible à l'exécution car le
266 processus serveur effectif peut être assemblé à l'exécution via la
267 directive <directive module="mod_so">LoadModule</directive> du fichier de
268 configuration <code>httpd.conf</code> plutôt que par des options du script
269 <program>configure</program> à la compilation. Par exemple,
270 on peut ainsi exécuter différentes instances du serveur
271 (standard et version SSL, version minimale et version étoffée
272 [mod_perl, PHP], <em>etc...</em>) à partir d'une seule installation
275 <li>Le paquetage du serveur peut être facilement étendu avec des modules
276 tiers, même après l'installation. Ceci présente en tout cas un gros
277 avantage pour les mainteneurs de paquetages destinés aux distributions,
278 car ils peuvent créer un paquetage Apache de base, et des paquetages
279 additionnels contenant des extensions telles que PHP, mod_perl, mod_fastcgi,
282 <li>Une facilité de prototypage des modules Apache car la paire
283 DSO/<program>apxs</program> vous permet d'une part de travailler en
284 dehors de l'arborescence des sources d'Apache, et d'autre part de n'avoir
285 besoin que de la commande <code>apxs -i</code>
286 suivie d'un <code>apachectl restart</code> pour introduire une nouvelle
287 version de votre module fraîchement développé dans le serveur Apache
288 en cours d'exécution.</li>
291 <p>Inconvénients des DSO :</p>
294 <li>Le mécanisme DSO n'est pas disponible sur toutes les plates-formes
295 car tous les systèmes d'exploitation ne supportent pas le chargement
296 dynamique de code dans l'espace d'adressage d'un programme.</li>
298 <li>Le serveur est environ 20 % plus lent au démarrage
299 à cause des résolutions de symboles supplémentaires que le chargeur
300 Unix doit effectuer.</li>
302 <li>Le serveur est environ 5 % plus lent à l'exécution
303 sur certaines plates-formes, car le code indépendant de la position (PIC)
304 nécessite parfois des manipulations compliquées en assembleur pour
305 l'adressage relatif qui ne sont pas toujours aussi rapides que celles
306 que permet l'adressage absolu.</li>
308 <li>Comme les modules DSO ne peuvent pas être liés avec d'autres
309 bibliothèques basées sur DSO (<code>ld -lfoo</code>) sur toutes les
311 (par exemple, les plates-formes basées sur a.out ne fournissent en
312 général pas cette fonctionnalité alors que les plates-formes basées sur
313 ELF le font), vous ne pouvez pas utiliser le mécanisme DSO pour tous les
314 types de modules. Ou en d'autres termes, les modules compilés comme
315 fichiers DSO sont contraints de n'utiliser que les symboles du coeur
316 d'Apache, de la bibliothèque C
317 (<code>libc</code>) et toutes autres bibliothèques statiques ou
318 dynamiques utilisées par le coeur d'Apache, ou d'archives statiques
319 (<code>libfoo.a</code>) contenant du code indépendant de la
321 Il y a deux solutions pour utiliser un autre type de code : soit le
322 coeur d'Apache contient déjà lui-même une référence au code, soit vous
323 chargez le code vous-même via <code>dlopen()</code>.</li>
projects / apache / blob