实现

　　为了简化创建Apache模块（尤其是第三方模块）的DSO文件的过程，apache提供了一个新工具名叫apxs（APache eXtenSion）。它可以脱离apache的源码将模块编译成DSO文件。它的实现思路非常简单: 在安装Apache时，configure脚本的 make install 过程会安装Apache的C头文件，并在apxs程序（apxs是一个perl脚本）中对依赖于具体平台的编译器和连接器设置一些标志(Flag)，以供创建DSO文件。通过这种方式，用户就可以利用apxs在没有Apache源码树且无需针对当前平台的编译器和连接器进行配置(以生成DSO格式目标文件)的情况下编译Apache模块了。

使用概要说明

1. 创建和安装一个 Apache发布的(distributed) 模块，比方说将mod_foo.c编译成mod_foo.so:
   
   $ ./configure --prefix=/path/to/install --enable-foo=shared
   $ make install
   
   
   
2. 创建和安装一个第三方的Apache模块，比方说将mod_foo.c编译成mod_foo.so:
   
   
   $ ./configure --add-module=module_type:/path/to/3rdparty/mod_foo.c --enable-foo=shared
   $ make install
   
   
   
3. 为以后安装（非HTTPD编译时安装）模块配置Apache:
   
   
   $ ./configure --enable-so
   $ make install
   
   (要编译全部Aapache模块，用./configure --enable-mods-shared=all --with-egd --with-devrandom --enable-so,但对experimental一类的模块，需要特别指定，如./configure --enable-mods-shared=all --with-egd --with-devrandom --enable-so --enable-cache=shared --enable-disk_cache=shared --enable-mem_cache=shared --enable-proxy=shared --enable-proxy_connect=shared --enable-proxy_ftp=shared --enable-proxy_http=shared --enable-file_cache=shared --enable-charset_lite=shared --enable-case_filter=shared --enable-case_filter_in=shared --enable-ssl=shared 。具体有哪些模块可以编译而没有打开编译开关，可在前面的那个configure运行的最后看看哪一个是no.)
   
4. 利用apxs在没有Apache源码树的情况下，创建和安装第三方的Apache模块:
   
   
   $ cd /path/to/3rdparty
   $ apxs -c mod_foo.c
   $ apxs -i -a -n foo mod_foo.la
   

背景知识

　　这种加载通过可以通过两种方式做到： 在一个可执行程序开始运行后通过一个叫ld.so的系统程序自动加载，或在可执行程序内部通过Unix加载器(loader)的系统编程接口的系统调用dlopen()/dlsym()来手工加载。

　　在第一种方式中，DSO通常被叫作共享库或DSO库，以libfoo.so或libfoo.so.1.2的形式命名。它们被存放在系统目录中（通常是/usr/lib），它们与可执行程序的联系是在编译这个可执行程序时，通过传递给连接器一个-lfoo参数来建立的。这里对库的引用直接编码在可执行程序中，因而在程序运行时，Unix加载器会通过以下途径寻找libfoo.so：在系统目录/usr/lib下，在通过-R连接参数传递给连接器后被编码在可执行程序中的路径中，在通过环境变量LD_LIBRARY_PATH指定的目录中。加载器会解析出来那些在可执行程序中使用但是在DSO定义的标志(symbol)。

　　可执行程序中的标志，通常不会被DSO引用（因为它是一个可重用的基本代码库），因而就不再进行进一步的解析。可执行程序自己不需要做任何事情就可以使用来自DSO的标志，因为Unix加载器已经做了相关的解析工作。(实际上，加载ld.so的代码是使用动态库的可执行程序启动代码的一部分). 动态加载基本代码库的优点是很明显的：库的代码只需在一个系统库（如libc.so）中保存一次，这样可以节省每个程序的磁盘空间。

　　在第二种方式中，DSO通常被叫作共享对象或DSO文件，命名它们时可以使用任意的扩展名，虽然规范的命名是foo.so的样子。这些文件通常存放在程序所在的目录（或子目录）中，它们与执行它们的程序没有自动建立的联系。相反，可执行程序在运行时通过dlopen手工将DSO加载。此时，来自DSO供执行程序用的标志没有被解析。相反，Unix加载器自动解析所有DSO中使用的来自可执行程序和它已经加载的DSO 库的标志(尤其是来自无处不在的libc.so的所有标志)。在这种方式中，DSO取得可执行程序的标志集合的信息，就象是被静态地连接到可执行程序中一样。

　　最后，为利用DSO's API，可执行程序须通过dlsym()来解析来自DSO的特定标志，供在以后的分派表等处使用。也就是说：可执行程序要想使用来自DSO的标志，须手工解析它。这样一种机制的优点，不需要的程序段不必加载(因而可以节省内存的使用) ，直到我们讨论的程序需要它时。当需要时，这些程序段可以被动态的加载，来扩展基本程序的功能。

　　虽然DSO机制听起来简单，用起来只少有一个比较困难的步骤，就是当用DSO来扩展程序的功能时（第二种方式）时，对来自可执行程序、供DSO使用的标志的解析。为什么呢? 因为"反向解析" DSO 使用的来自可执行程序标志集合的标志是与函数库的设计相逆的 (函数库没有任何关于那些使用它的程序的信息)，而且没有平台提供这种功能，这也不是一个标准化的功能。实际上，可执行程序的全局标志常常不能再次输出，因而也无法供DSO使用。要利用DSO来动态扩展一个程序的功能，找到一种方法来强制连接器输出所有全局标志是必须解决的主要问题。

　　共享库的方法就是一个典型，因为它是DSO机制最初设计的目标，因而它被用于操作系统提供的几乎所有类型的函数库中。从另一方面来说，利用共享对象来扩展功能的程序并不是很多。

　　到1998年，只有很少的软件包在程序运行时利用DSO机制来扩展它们的功能：Perl 5(通过它的XS机制和DynaLoader模块）, Netscape Server,等。从版本1.3开始, Apache 也加入了这个群体，因为Apache早就用模块的概念来扩展它的功能，且在内容利用基于分派链（dispatch-list-based ）的方法来将外部的模块连接到Apache的核心功能中。因此，Apache实际上注定要用DSO来在运行时加载模块的。

长处和不足

• 服务器在运行时更加灵活，因为实际的服务器进程可以通过配置文件的LoadModule命令动态的组配，而不必在编译时通过配置参数指定。例如，通过这种方式，虽然只安装了一次，但服务器可以以多种形态运行（如标准版本或SSL版本，简化版本或增强版本[含mod_perl,php3等])
  
• 即使在安装完成后，服务器仍可以很方便地用第三方的模块进行功能扩展。这至少对销售商的软件支持有帮助，他们可以创建一个apache的核心程序包，和一个包含PHP3, mod_perl, mod_fastcgi等扩展功能的扩展包。
• 
  
• 更容易地开发 Apache模块原型，因为借用DSO和apxs，你可以脱离Apache的源码而只需apxs -i命令就可以开发和编译模块，利用apachectl restart 命令，就可以让新开发的模块在在apache服务器中运行。

DSO 也有下列不足：:

• DSO并不是在任何平台都可以使用，因为有一些平台不支持动态将一段代码加载到另一个程序的地址空间中
  
• 服务器在启动时慢大约20%，因为加载器要作标志解析。
  
• 在运行时，在有些平台上服务器大约慢5%，因为PIC（ position independent code ）代码需要更复杂的组配技巧来解决相对地址的问题，而对绝对地址的情况没有这种开销所以会快一些。
  
• 因为并不是所有的平台都支持DSO模块连接(ld -lfoo)其它基于DSO的库（如基于out的平台通常不提供这个功能而基于ELF的平台则可以）,所以不能将DSO机制用于所有类型的模块。换句话说，可以编译为DSO文件的模块限制为那些：引用的标志只来自apache内核、来自C函数库(libc)、来自其它的Aapche内核使用的动态或静态库、或含有PIC代码的静态库文件（libfoo.a）。使用其它代码的唯一机会，要么确定apache内核已经对此引用，要能自己通过dlopen()加载代码。

参考文献：
Dynamic Shared Object (DSO) Support