Building Apache the Way You Want It - Configuring Apache 2 for Cross-Platform Builds (Page 11 of 13 )
One of Apache’s great strengths is its ability to run on almost any platform. Apache 2 improves on this with the APR libraries, which greatly enhance Apache’s ability to adapt to a new platform by providing a portability layer of common functions and data structures. You can find detailed information on the APR on the APR project pages at http://apr.apache.org/.
Between the APR and the adoption of the autoconf system for build configuration, you now have the ability to configure and build Apache for a different platform and even a different processor, if you have a cross-platform compiler available. Many compilers are capable of cross-compliation, including gcc, but not by default; you generally need to build a cross-compiling version of the compiler first. You also need accompanying compiler tools such as ld, ar, and ranlib—on Linux platforms these are generally in the binutils package. Consult the documentation for the installed compiler for information.
Once you have a cross-compiler set up, you can use it to build Apache. To do this, specify one or more of the portability options --target, --host, and --build. All three of these options take a parameter of the form CPU-VENDOR-SYSTEM or CPU-VENDOR-OS-SYSTEM and work together as shown in Table 3-9.
Table 3-9. Configure Script Build Options
Option | Description |
--host | The system type of the platform that’ll actually run the server. |
--target | The system type of the platform for which compiler tools will produce code. This isn’t in fact the target system (that’s the host), but a definition that’s passed on to compiler tools that are themselves built during the build process. Normally this would be the same as the host, which it defaults to. |
--build | The system type of the platform that will carry out the build. This defines your own server when the host is set to something different. It defaults to host. |
These three values are used by the autoconf system, on which the Apache 2 build configuration is based. As a practical example of a host value, a Pentium III server running Linux would usually be defined as i786-pc-linux-gnu. This would be used for the host, if it’s the system that you’ll be running Apache on, and the build host, if it’s the system that’ll be building Apache. In most cases, all three values are the same, with the target and build types defaulting to the host type. It’s rare that all three are needed. You can find detailed information about them in the autoconf manual pages at http://www.lns.cornell.edu/public/COMP/info/autoconf/.
Normally, configure will guess the host processor, platform vendor, and operating system type automatically; then default the build and target to it for a local build. Alternatively, you can override the host using the --host option or adding it to the end of the command line as a nonoption. This allows you to specify a different platform. For instance, to build for a Sparc-based server running Solaris like so:
$ ./configure --build=i786-pc-linux-gnu --host=sparc-sun-solaris2
it’s necessary to specify both the host and build system types when cross-compiling. This is because the build system type defaults to the host if not set explicitly. (This is the correct behavior when not cross-compiling but where the guessed host system type is incorrect.) Another reason is that cross-compilers can’t always correctly determine the build system. If it can, you can just use local instead of a complete system type definition:
$ ./configure --build=local --host=sparc-sun-solaris2
It might be necessary to specify the compiler explicitly if you have both a native compiler and a cross-compiler on the same build host; configure will generally find the native compiler first, and you need to tell it otherwise. To do that, you can set the name of the compiler in the environment variable CC like this:
$ CC=/path/to/cross/compiler ./configure ... --build=i786-pc-linux-gnu
--host=sparc-sun-solaris2
Alternatively, if the cross-compiler has a distinct and different name and is on your path, you can just specify the name and leave out the path. See “Configuring the Build Environment” later in the chapter for more about how you can use environment variables to control the configuration process.
Configuring Apache for Production or Debug Builds Normally you want to produce a server executable that has debugging information stripped from it and is compiled with any optimizations available for a more efficient server. However, Apache comes with full source code, so if you want, you can build a version of the server for debugging purposes. Several options are available to help with this, more in Apache 2 than in Apache 1.3 (see Table 3-10).
Table 3-10. Configure Script Debug Options
Option | Description | Compatibility |
--without-execstrip | In Apache 1.3, this tells the build process to | Apache 1.3 only |
| disable optimizations and not to strip the | |
| symbol tables out of the resulting Apache | |
| binary so it can be debugged. This is also | |
| helpful for analyzing core files left by a | |
| crashed Apache process after the fact. | |
--enable-maintainer-mode | This is the Apache 2 equivalent of | Apache 2 only |
--enable-debug | --without-execstrip and similarly | |
| produces a binary for debugging. It also | |
| turns on some additional compile-time | |
| debug and warning messages. | |
--enable-profile | Switches on profiling for the Apache | Apache 2 only |
| Portable Runtime; for debugging only. | |
--enable-assert-memory | Switches on memory assertions in the | Apache 2 only |
| Apache Portable Runtime; for debugging | |
| only. | |
A few other more specialized options are also available; see the bottom of the output from ./srclib/apr/configure --help for a complete—if rather terse—list of them. --enable-v4-mapped, for example, tells Apache that it can use IPv6 sockets to receive IPv4 connections. Because this is highly dependent on the operating system, it’s usually best to let configure choose these options for you. Many of these are general autoconf options rather than Apache-specific ones, and you can find more information about them in the autoconf documentation at http://www.lns.cornell.edu/public/COMP/
info/autoconf/.
Configuring Apache for Binary Distribution Apache may also be compiled as a distributable binary archive, which may be copied to other machines, unpacked, and installed. To do this, you must build it using the BinaryDistribution layout and make use of the binbuild.sh script, which is included in the build directory under the root of the source distribution. See “The Binary Distribution Layout” section earlier in the chapter where this is described in detail.
Configuring Apache’s Library and Include Paths Apache relies on a lot of external libraries and headers to build itself. Various parts of the server require additional libraries and headers, or they’ll either disable themselves or be built with reduced functionality. As usual, options are available to help you teach Apache where to look for external libraries and their attendant headers and where to install its own so that utilities such as apxs can find them. Not all of these are listed by configure --help, but some can be found running this:
srclib/package/configure -help
where package is one of apr, apr-util, or pcre.
You can subdivide these options into two loose categories: general options and module-specific options.
General Options
Table 3-11 lists the general options.
Table 3-11. Configure Script General Options
Option | Description |
--includedir | The location of Apache’s include files. Default PREFIX/include. This is a layout option (see Table 3-5). |
--oldincludedir | The location of header files outside the Apache source distribution. The default is /usr/include. |
--libdir | The location of Apache’s own libraries. The default is PREFIX/lib. A layout option (see earlier). |
You can specify external library and include paths with the -I and -L compiler options, for example:
$ CFLAGS="-I/home/my/includes -I/home/other/includes -L/home/my/lib/"
./configure ...
Module- and Package-Specific Options
Table 3-12 lists the module-specific options.
Table 3-12. Configure Script Module and Package Options
Option | Description |
--with-apr=DIR | Specifies the location of the APR headers, if you already happen to |
| have one built and installed elsewhere. (The APR is available as a |
| separate package from http://apr.apache.org/.) |
--with-dbm=DBMTYPE Specifies the type of DBM database to use. This is used by mod_auth_dbm |
and the DBM map feature of mod_rewrite. The default is to use SDBM, |
which comes bundled with Apache but that has limited functionality. |
A local version of a more powerful DBM such as GDBM can be |
specified with --with=dbm=gdbm. |
--with-expat=DIR | Specifies the location of the Expat library and header files. configure |
| will try several different permutations based on the base directory |
| path specified by DIR; the default is to try /usr and /usr/local. |
--with-ssl=DIR | Specifies the location of the OpenSSL library and header files, if |
| mod_ssl has been enabled. Limited support for other SSL |
| implementations is also available. |
--with-z=DIR | Specifies the location of the Zlib compression library and header files, |
| if mod_deflate has been enabled. |
Next: Configuring the Build Environment >>
More Apache Articles
More By Apress Publishing
|
 This article is from chapter three of the book Pro Apache third edition, written by Peter Wainwright (Apress, 2004; ISBN: 1590593006). Check it out at your favorite bookstore. Buy this book now.
|
|
