Before building and installing mod_perl you
will have to configure it, as you would configure any other Perl
module:
panic% perl Makefile.PL [parameters].
Perl Installation Requirements
Make sure you have Perl installed! Use the latest stable
version, if possible. To determine
your version of Perl, run the following command on the command line:
panic% perl -v
You will need at least Perl Version 5.004. If you
don't have it, install it. Follow the instructions
in the distribution's INSTALL
file. The only thing to watch for is that during the configuration
stage (while running ./Configure) you make sure
you can dynamically load Perl module extensions. That is, answer
YES to the following question:
Do you wish to use dynamic loading? [y]
|
In this section, we will explain each of the parameters accepted by
the Makefile.PL file for mod_perl First,
however, lets talk about how the mod_perl configuration dovetails
with Apache's configuration. The source
configuration mechanism in Apache 1.3 provides four major features
(which of course are available to mod_perl):
-
Apache
modules can use per-module
configuration scripts to link themselves into
the Apache configuration process. This feature lets you automatically
adjust the configuration and build parameters from the Apache module
sources. It is triggered by
ConfigStart/ConfigEnd sections inside
modulename.module files (e.g., see the file
libperl.module in the mod_perl distribution).
-
The APache AutoConf-style
Interface (APACI)
is the top-level
configure script from Apache 1.3; it provides a
GNU Autoconf-style interface to the
Apache configuration process. APACI is useful for configuring the
source tree without manually editing any
src/Configuration files. Any parameterization
can be done via command-line options to the
configure script. Internally, this is just a
nifty wrapper over the old src/Configure script.
Since Apache 1.3, APACI is the best way to install mod_perl as
cleanly as possible. However, the complete Apache 1.3 source
configuration mechanism is available only under Unix at this
writing—it doesn't work on Win32.
-
Dynamic shared object (DSO)
support is one of the most
interesting features in Apache 1.3. It allows Apache
modules to be built as so-called DSOs
(usually named modulename.so), which can be
loaded via the
LoadModule
directive in Apache's
httpd.conf file. The benefit is that the modules
become part of the httpd executable only on
demand; they aren't loaded into the address space of
the httpd executable until the user asks for
them to be. The benefits of DSO support are most evident in relation
to memory consumption and added flexibility (in that you
won't have to recompile your
httpd each time you want to add, remove, or
upgrade a module).
The DSO mechanism is provided by Apache's
mod_so
module, which needs to be compiled into the
httpd binary with:
panic% ./configure --enable-module=so
The usage of any —enable-shared option
automatically implies an —enable-module=so
option, because the bootstrapping module mod_so is
always needed for DSO support. So if, for example, you want the
module mod_dir to be built as a DSO, you can
write:
panic% ./configure --enable-shared=dir
and the DSO support will be added automatically.
-
The APache eXtension
Support tool (APXS)
is a tool from Apache 1.3 that can be used to build an Apache module
as a DSO even outside the Apache source tree. APXS
is to Apache what
MakeMaker
and XS are to Perl.[16] It knows the
platform-dependent build parameters for making DSO files and provides
an easy way to run the build commands with them.
[16]MakeMaker allows easy, automatic
configuration, building, testing, and installation of Perl modules,
while XS allows you to call functions implemented
in C/C++ from Perl code.
Pros and Cons of Building mod_perl as a DSO
As of Apache 1.3, the configuration system
supports two optional features for taking advantage of the modular
DSO approach: compilation of the Apache core program into a DSO
library for shared usage, and compilation of the Apache modules into
DSO files for explicit loading at runtime.
Should you build mod_perl as a DSO? Let's study the
pros and cons of this installation method, so you can decide for
yourself.
Pros:
-
The server package is
more flexible because the actual
server executable can be assembled at runtime via
LoadModule configuration commands in
httpd.conf instead of via
AddModule commands in the
Configuration file at build time. This allows
you to run different server instances (e.g., standard and SSL
servers, or servers with and without mod_perl) with only one Apache
installation; the only thing you need is different configuration
files (or, by judicious use of IfDefine, different
startup scripts).
-
The server package can
easily be extended with
third-party
modules even
after installation. This is especially helpful for vendor package
maintainers who can create an Apache core package and additional
packages containing extensions such as PHP, mod_perl, mod_fastcgi,
etc.
-
DSO support allows easier Apache
module prototyping, because with the
DSO/APXS pair you can work outside the Apache
source tree and need only an apxs -i command
followed by an apachectl restart to bring a new
version of your currently developed module into the running Apache
server.
Cons:
-
The DSO mechanism cannot be used on every platform,
because not all operating systems support shared libraries.
-
The server starts up
approximately 20% slower because of the
overhead of the symbol-resolving the Unix loader now has to do.
-
The server runs approximately 5% slower on some platforms, because
position-independent code (PIC) sometimes needs complicated assembler
tricks for relative addressing, which are not necessarily as fast as
those for absolute addressing.
-
Because DSO modules cannot be linked against other DSO-based
libraries (ld -lfoo) on all platforms (for
instance, a.out-based platforms usually
don't provide this functionality, while ELF-based
platforms do), you cannot use the DSO mechanism for all types of
modules. In other words, modules compiled as DSO files are restricted
to use symbols only from the Apache core, from the C library
(libc) and from any other dynamic or static
libraries used by the Apache core, or from static library archives
(libfoo.a) containing position-independent code.
The only way you can use other code is to either make sure the Apache
core itself already contains a reference to it, load the code
yourself via dlopen( ), or enable the
SHARED_CHAIN rule while building Apache (if your
platform supports linking DSO files against DSO libraries). This,
however, won't be of much significance to you if
you're writing modules only in Perl.
-
Under some platforms (e.g., many SVR4 systems), there is no way to
force the linker to export all global symbols for use in DSOs when
linking the Apache httpd executable program. But
without the visibility of the Apache core symbols, no standard Apache
module could be used as a DSO. The only workaround here is to use the
SHARED_CORE feature, because in this way the
global symbols are forced to be exported. As a consequence, the
Apache src/Configure script automatically
enforces SHARED_CORE on these platforms when DSO
features are used in the Configuration file or
on the configure command line.
|
Together, these four features provide a way to integrate mod_perl
into Apache in a very clean and smooth way. No patching of the Apache
source tree is usually required, and for APXS
support, not even the Apache source tree is needed.
To benefit from the above features, a hybrid build environment was
created for the Apache side of mod_perl. See Section 3.5, later in this chapter, for details.
Once the overview of the four building steps is complete, we will
return to each of the above configuration mechanisms when describing
different installation passes.
