From 2624750e1f61e392bcf6f4e3ade841e29c0b0df7 Mon Sep 17 00:00:00 2001 From: "Ralf S. Engelschall" Date: Fri, 15 May 1998 09:16:22 +0000 Subject: [PATCH] fix typos git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@81282 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/dso.html | 12 ++++++------ docs/manual/dso.html.en | 12 ++++++------ 2 files changed, 12 insertions(+), 12 deletions(-) diff --git a/docs/manual/dso.html b/docs/manual/dso.html index 03e63927de..0d79f7ee67 100644 --- a/docs/manual/dso.html +++ b/docs/manual/dso.html @@ -44,7 +44,7 @@ to the Unix loader through the system calls dlopen()/dlsym(). libfoo.so.1.2. They reside in a system directory (usually /usr/lib) and the link to the executable program is established at build-time by specifying -lfoo to the linker command. This -hardcodes library references into the executable program file so that at +hard-codes library references into the executable program file so that at start-time the Unix loader is able to locate libfoo.so in /usr/lib, in paths hard-coded via linker-options like -R or in paths configured via the environment variable @@ -52,7 +52,7 @@ start-time the Unix loader is able to locate libfoo.so in the executable program which are available in the DSO.

Symbols in the executable program are usually not referenced by the DSO -(because it's a reuseable library of general code) and hence no further +(because it's a reusable library of general code) and hence no further resolving has to be done. The executable program has no need to do anything on its own to use the symbols from the DSO because the complete resolving is done by the Unix loader. (In fact, the code to invoke ld.so is part of @@ -137,11 +137,11 @@ third-party modules) a new support program named apxs (APache eXtenSion) is available. It can be used to build DSO based modules outside of the Apache source tree. The idea is simple: When installing Apache the configure's make install -procedure installs the Apache C header files and puts the platform-dependend +procedure installs the Apache C header files and puts the platform-dependent compiler and linker flags for building DSO files into the apxs program. This way the user can use apxs to compile his Apache module sources without the Apache distribution source tree and without having -to fiddle with the platform-dependend compiler and linker flags for DSO +to fiddle with the platform-dependent compiler and linker flags for DSO support.

To place the complete Apache core program into a DSO library (only required @@ -351,7 +351,7 @@ $ apxs -i -a -n foo mod_foo.so symbol resolving overhead the Unix loader now has to do.

  • The server is approximately 5% slower at execution time under some - platforms because position independed code (PIC) sometimes needs + platforms because position independent code (PIC) sometimes needs complicated assembler tricks for relative addressing which are not necessarily as fast as absolute addressing.

    @@ -363,7 +363,7 @@ $ apxs -i -a -n foo mod_foo.so 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 + independent 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().

    diff --git a/docs/manual/dso.html.en b/docs/manual/dso.html.en index 03e63927de..0d79f7ee67 100644 --- a/docs/manual/dso.html.en +++ b/docs/manual/dso.html.en @@ -44,7 +44,7 @@ to the Unix loader through the system calls dlopen()/dlsym(). libfoo.so.1.2. They reside in a system directory (usually /usr/lib) and the link to the executable program is established at build-time by specifying -lfoo to the linker command. This -hardcodes library references into the executable program file so that at +hard-codes library references into the executable program file so that at start-time the Unix loader is able to locate libfoo.so in /usr/lib, in paths hard-coded via linker-options like -R or in paths configured via the environment variable @@ -52,7 +52,7 @@ start-time the Unix loader is able to locate libfoo.so in the executable program which are available in the DSO.

    Symbols in the executable program are usually not referenced by the DSO -(because it's a reuseable library of general code) and hence no further +(because it's a reusable library of general code) and hence no further resolving has to be done. The executable program has no need to do anything on its own to use the symbols from the DSO because the complete resolving is done by the Unix loader. (In fact, the code to invoke ld.so is part of @@ -137,11 +137,11 @@ third-party modules) a new support program named apxs (APache eXtenSion) is available. It can be used to build DSO based modules outside of the Apache source tree. The idea is simple: When installing Apache the configure's make install -procedure installs the Apache C header files and puts the platform-dependend +procedure installs the Apache C header files and puts the platform-dependent compiler and linker flags for building DSO files into the apxs program. This way the user can use apxs to compile his Apache module sources without the Apache distribution source tree and without having -to fiddle with the platform-dependend compiler and linker flags for DSO +to fiddle with the platform-dependent compiler and linker flags for DSO support.

    To place the complete Apache core program into a DSO library (only required @@ -351,7 +351,7 @@ $ apxs -i -a -n foo mod_foo.so symbol resolving overhead the Unix loader now has to do.

  • The server is approximately 5% slower at execution time under some - platforms because position independed code (PIC) sometimes needs + platforms because position independent code (PIC) sometimes needs complicated assembler tricks for relative addressing which are not necessarily as fast as absolute addressing.

    @@ -363,7 +363,7 @@ $ apxs -i -a -n foo mod_foo.so 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 + independent 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().

    -- 2.40.0