rse 98/05/06 08:44:31
Modified: . README.configure INSTALL src README.DSO Log: Make some documents up-to-date for the 1.3b7 release. Revision Changes Path 1.8 +19 -20 apache-1.3/README.configure Index: README.configure =================================================================== RCS file: /export/home/cvs/apache-1.3/README.configure,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- README.configure 1998/04/29 06:24:53 1.7 +++ README.configure 1998/05/06 15:44:25 1.8 @@ -78,9 +78,10 @@ Additionally if some of the shown paths still don't fit for your particular situation, you can use the --bindir, --sbindir, --libexecdir, --mandir, - --sysconfdir, --datadir and --localstatedir options to adjust the layout as - required. Always check with --layout the resulting directory layout which - would be used for installation. + --sysconfdir, --datadir, --localstatedir, --runtimedir, --logfiledir and + --proxycachedir options to adjust the layout as required. Always check with + --layout the resulting directory layout which would be used for + installation. suEXEC support -------------- @@ -116,15 +117,15 @@ Then APACI first determines the GNU platform triple, creates a shadow tree in src.<gnu-triple> plus corresponding Makefile.<gnu-triple> and then - performs the complete build process with this shadow tree. + performs the complete build process inside this shadow tree. Dynamic Shared Object (DSO) support ----------------------------------- - Apache 1.3 supports building modules as shared objects on all major + Apache 1.3 supports building modules as shared objects on all major Unix platforms (see section "Supported Platforms" in file src/README.DSO for - details). APACI has a nice way of enabling the building of these shared - objects and automatically installing them: + details). APACI has a nice way of enabling the building of DSO-based + modules and automatically installing them: $ ./configure --prefix=/path/to/apache \ --enable-module=rewrite \ @@ -134,11 +135,9 @@ This builds and installs Apache with the default configuration except that it adds the mod_rewrite module and automatically builds and installs it as a - shared object, so it is optionally available for loading under runtime. To - make your live even more easy APACI additionally inserts a corresponding - (but out-commented) `LoadModule' line in the httpd.conf file in the - installation phase. Just uncomment this line and you have mod_rewrite - available. + DSO, so it is optionally available for loading under runtime. To make your + life even more easy APACI additionally inserts a corresponding `LoadModule' + line into the httpd.conf file in the installation phase. APACI also supports a variant of the --enable-shared option: @@ -149,7 +148,7 @@ This enables shared object building for the maximum of modules, i.e. all enabled modules (--enable-module or the default set) except for mod_so - itself (the bootstrapping module for shared object support). So, to build a + itself (the bootstrapping module for DSO support). So, to build a full-powered Apache with maximum flexibility by building and installing most of the modules, you can use: @@ -162,8 +161,8 @@ This first enables most of the modules (all modules except some problematic ones like mod_auth_db which needs third party libraries not available on every platform or mod_log_agent and mod_log_referer which are deprecated) - and then enables shared object support for all of them. This way you get all - these modules installed and you then can configure under runtime (via the + and then enables DSO support for all of them. This way you get all these + modules installed and you then can decide under runtime (via the `LoadModule') directives which ones are actually used. Especially a very useful for vendor package maintainers to provide a flexible Apache package. @@ -184,7 +183,7 @@ This automatically copies mod_foo.c to src/modules/extra/, activates it in the configuration and builds Apache with it. A very useful way is to combine - this with the shared object support: + this with the DSO support: $ ./configure --prefix=/path/to/apache \ --add-module=/path/to/mod_foo.c \ @@ -193,8 +192,8 @@ $ make install This builds and installs Apache with the default set of modules, but - additionally builds mod_foo as a shared object and adds a `LoadModule' line - to the httpd.conf file, so later you can enable this mod_foo under runtime. + additionally builds mod_foo as a DSO and adds a `LoadModule' line to the + httpd.conf file to activate it for loading under runtime. Apache and mod_perl ------------------- @@ -206,7 +205,7 @@ mod_perl-1.XX.tar.gz can be found on http://perl.apache.org/src/. Here is how you can install Apache with mod_perl: - $ cd mod_perl-1.XX + $ cd mod_perl-1.11 $ perl Makefile.PL ReadLine support enabled Configure mod_perl with ../apache-1.3/src ? [y] y @@ -222,7 +221,7 @@ This automatically builds and installs Apache 1.3 with mod_perl. After additionally installing the Perl side of mod_perl via - $ cd ../mod_perl-1.XX + $ cd ../mod_perl-1.11 $ perl Makefile.PL NO_HTTPD=1 $ make all install 1.25 +31 -25 apache-1.3/INSTALL Index: INSTALL =================================================================== RCS file: /export/home/cvs/apache-1.3/INSTALL,v retrieving revision 1.24 retrieving revision 1.25 diff -u -r1.24 -r1.25 --- INSTALL 1998/05/06 15:17:56 1.24 +++ INSTALL 1998/05/06 15:44:26 1.25 @@ -9,16 +9,15 @@ Introduction ============ - Like all good things, there are two ways to configure, compile, and - install Apache. You can go for the 3-minute installation process - using the APACI process described below; or, you can opt for the same - mechanism used in previous versions of Apache, as described in the - file 'src/INSTALL'. Each mechanism has its benefits and drawbacks - - APACI is newer and a little more raw, but it gets you up and running - the least amount of time, whereas the "Configuration.tmpl" mechanism - may be more familiar and give you some more flexibility to the power - user. We'd be very interested in your comments and feedback regarding - each approach. + Like all good things, there are two ways to configure, compile, and install + Apache. You can go for the 3-minute installation process using the APACI + process described below; or, you can opt for the same mechanism used in + previous versions of Apache, as described in the file 'src/INSTALL'. Each + mechanism has its benefits and drawbacks - APACI is newer and a little more + raw, but it gets you up and running the least amount of time, whereas the + "Configuration.tmpl" mechanism may be more familiar and give you some more + flexibility to the power user. We'd be very interested in your comments and + feedback regarding each approach. Installing the Apache 1.3 HTTP server with APACI @@ -47,22 +46,23 @@ o ANSI-C Compiler: Make sure you have an ANSI-C compiler installed. The GNU C compiler - (GCC) from the Free Software Foundation (FSF) is recommended. If you - don't have GCC then at least make sure your vendors compiler is ANSI - compliant. You can find the homepage of GNU at - http://www.gnu.ai.mit.edu/ and the GCC distribution under + (GCC) from the Free Software Foundation (FSF) is recommended (version + 2.7.2 is fine). If you don't have GCC then at least make sure your + vendors compiler is ANSI compliant. You can find the homepage of GNU + at http://www.gnu.ai.mit.edu/ and the GCC distribution under http://www.gnu.ai.mit.edu/order/ftp.html . o Perl 5 Interpreter [OPTIONAL]: For some of the support scripts like `apxs' or `dbmmanage' (which are - written in Perl) the Perl 5 interpreter is required. If no such - interpreter is found by APACI's `configure' script this is no harm. - Of course, you still can build and install Apache 1.3. Only those - support scripts cannot be used. If you have multiple Perl interpreters - installed (perhaps a Perl 4 from the vendor and a Perl 5 from your - own), then it is recommended to use the --with-perl option (see below) - to make sure the correct one is selected by APACI. + written in Perl) the Perl 5 interpreter is required (versions 5.003 + and 5.004 are fine). If no such interpreter is found by APACI's + `configure' script this is no harm. Of course, you still can build + and install Apache 1.3. Only those support scripts cannot be used. If + you have multiple Perl interpreters installed (perhaps a Perl 4 from + the vendor and a Perl 5 from your own), then it is recommended to use + the --with-perl option (see below) to make sure the correct one is + selected by APACI. o Dynamic Shared Object (DSO) support [OPTIONAL]: @@ -83,7 +83,7 @@ - Solaris o Entirely unsupported platforms are: - - Ultrix (because no dlopen-style interface) + - Ultrix If your system is not on these lists but has the dlopen-style interface, you either have to provide the appropriate compiler and @@ -119,7 +119,7 @@ with a particular compiler and flags plus the two additional modules mod_rewrite and mod_proxy for later loading through the DSO mechanism: - $ CC="pgcc" OPTIM="-O6" \ + $ CC="pgcc" OPTIM="-O2" \ ./configure --prefix=/sw/pkg/apache \ --enable-module=rewrite --enable-shared=rewrite \ --enable-module=proxy --enable-shared=proxy @@ -244,6 +244,12 @@ a --enable-module=so option because the bootstrapping module mod_so is always needed for DSO support. + Note 4: When you later want to extend your Apache installation via + third-party modules through the DSO+APXS mechanism make sure + that you at least compile with mod_so included, even when no + distributed modules are build as shared objects. This can be + achieved by explicitly using --enable-module=so. + Use the --with-perl=FILE option to select a particular Perl interpreter executable to be used with Apache. Per default APACI tries to find it automatically. But if multiple Perl instances exist on your system you @@ -277,8 +283,8 @@ $ make Please be patient here, this takes approximately 2 minutes to complete - under a Pentium-166/FreeBSD-2.2 system, dependend on the amount of modules - you have enabled. + under a Pentium-166/FreeBSD-2.2 system, dependend on the amount of + modules you have enabled. 5. Installing the package ---------------------- 1.9 +15 -14 apache-1.3/src/README.DSO Index: README.DSO =================================================================== RCS file: /export/home/cvs/apache-1.3/src/README.DSO,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- README.DSO 1998/05/02 11:15:08 1.8 +++ README.DSO 1998/05/06 15:44:29 1.9 @@ -277,22 +277,23 @@ In other words: When a module is compiled as a DSO it automatically results in a higher priority than any statically compiled modules. This - can have strange side-effects because of different execution order. As a - consequence the rule of thumb is this: Either compile all modules - statically or all modules as DSO (--enable-shared=max) when you want to - avoid side-effects. And only compile just a subset of modules as DSO when - you are sure the different execution order has no side-effects for your - configuration. BE WARNED! + can have strange side-effects because of different execution order. To + overcome this problem the Apache installation process automatically + inserts ClearModuleList+AddModule directives into the initial httpd.conf + file which re-create the chained list of modules in the correct order. + So whenever you change the list of loaded modules make sure to also + update this ClearModule+AddModule directives accordingly. - Because DSO modules cannot be linked against other DSO-based libraries - (ld -lfoo) you cannot use the DSO mechanism for all types of modules. Or - in other words, modules compiled as DSO files are restricted to only use - symbols from the Apache core, from the C library (libc) and all other - dynamic or static libraries used by the Apache core, or from static - library archives (libfoo.a) containing position independend code. The - only chance to use other code is to either make sure the Apache core - itself already contains a reference to it or loading the code yourself - via dlopen(). + (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. Or in other words, + modules compiled as DSO files are restricted to only use symbols from the + Apache core, from the C library (libc) and all other dynamic or static + libraries used by the Apache core, or from static library archives + (libfoo.a) containing position independend code. The only chance to use + other code is to either make sure the Apache core itself already contains + a reference to it or loading the code yourself via dlopen(). - Under some platforms (many SVR4 systems) there is no way to force the linker to export all global symbols for use in DSO's when linking the