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 -vYou 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.
Continue to:
Creative Commons License
Written by
Eric Cholet (Logilune) and
Stas Bekman (StasoSphere & Free Books).