You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by rs...@hyperreal.org on 1998/05/06 17:44:31 UTC
cvs commit: apache-1.3/src README.DSO
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