How To Build the Apache of Your Dreams - Diversion: Shared Modules (mod_so) (
Page 4 of 8 )
mod_so
is a special case, and deserves special treatment, since it may affect how many
of the other modules are built. mod_so enables modules to be linked into Apache
at run time, rather than at compile time (i.e., when httpd is started). This is
similar to how shared libraries operate under Unixen (or DLL's under Win32).
Normally, compiling Apache produces a single, self-contained executable named
httpd, but with mod_so, modules can be compiled as shared object files. These
are kept separate from the httpd binary, and are activated in configuration
files. This allows, for example, several copies of Apache (bound to different
interfaces, or on different boxes sharing a common NFS share) to run differently
configured httpd processes while the administator only has to maintain one
Apache install.
Up to Apache 1.3, mod_so was unstable, but at this point
it is considered solid and can be used in production environments. However,
there are some moules that perform differently or have different capabilities if
built shared. For example, if mod_perl is not compiled staticly, it will lack
the Perl SSI capabilities, because mod_include required defines that are only
defined if mod_perl is not compiled shared. For the most part, however, standard
modules behave identically regardless of whether they are built shared or
statically. In fact, some folks prefer to compile mod_so statically, and have
everything else as shared modules.
--enable-shared is used in conjunction
with mod_so, and allows specific modules to be built as shared modules so they
can be loaded into the httpd binary. If mod_so is built into the server
(--enable-module=so), any module that is to be built in this way should be
mentioned in an enable-shared parameter. For example compiling the Proxy and
Rewrite modules this way would require --enable-module=proxy
--enable-module=rewrite --enable-shared=proxy --enable-shared=rewrite to be
passed to the configure script. Note that both --enable-module and
--enable-shared are required.
Adding shared modules after the main job of
configuring and compiling the server is completed is made simple by one of the
included utility programs, called apxs. This script takes one or more of a
number of options and invokes your compiler to compile the module, and
optionally put it into place and activate it in the server config file. Enabling
mod_so is particularly useful for developers who are writing modules in C, since
modules are kept separate (as .so files on Unix or .dll files on Win32) and
updating a module is as simple as recompiling the shared module with the
included tool apxs and restarting the server. Without mod_so and shared modules,
any change, however small, to a C source file requires a compelte recompilation
of Apache.
When using mod_so and apxs, if your copy of Perl is in a
non-standard location (something other than /usr/bin/perl or
/usr/local/bin/perl), you should use the command --with-perl=/path/to/perl,
since apxs is a Perl script and needs to point to the correct
Perl.
{mospagebreak title=Configuration Methods, and the Modules Who Love
Them} Up to Apache 1.3, configuration was handled by editing a file called
Configuration, which contained directives that were used to generate Makefiles.
As of Apache 1.3, however, there is another option for creating Makefiles, based
on GNU autoconf. This new method is called the APache AutoConf-style Interface
(APACI), and is much simpler to use; the script is called configure. The syntax
of the configure script, in condensed form, can be obtained by typing
./configure --help. (Since configuration is usually done as root, and "." should
never be in root's path, all example of using configure will be referred to as
"./configure".)
Configuration via the configure script is controlled by
passing command-line options. The main options that will be used to create the
Makefile are --enable-module/--disable-module, --enable-shared, and
--with-layout.
The --enable-module switch is used to enable one of the
standard modules. This switch is only necessary for enabling modules that are
not enabled by default. Similarly, the --disable-module switch is for disabling
modules that are enabled by default but are not desired or needed.
Using
--enable-module or --disable-module requires the name of the module, without the
initial mod_, so, for example to enable the Proxy module, you would pass
--enable-module=proxy, and disabling the AutoIndexing module requires passing
--disable-module=autoindex.
