general/2628: Archive (.a) libraries are built for Apache's own code, but not shared (.so or .sl) libraries

[Richard Lloyd <rk...@connect.org.uk>]

>Number:         2628
>Category:       general
>Synopsis:       Archive (.a) libraries are built for Apache's own code, but not shared (.so or .sl) libraries
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    apache
>State:          open
>Class:          change-request
>Submitter-Id:   apache
>Arrival-Date:   Wed Jul 15 07:40:00 PDT 1998
>Last-Modified:
>Originator:     rkl@connect.org.uk
>Organization:
apache
>Release:        1.3.0
>Environment:
All systems (though I'm using HP-UX 10.20)
>Description:
The following archive libraries are built in the Apache source tree:

./src/ap/libap.a
./src/main/libmain.a
./src/modules/standard/libstandard.a
./src/os/unix/libos.a
./src/regex/libregex.a

It's not clear why shared library versions (e.g. .so or .sl) aren't built
too, for linking against the main binaries.
>How-To-Repeat:
Affects the build of all systems. The final httpd binary with no extra
modules is over 300K. With shared library versions, this would reduce
dramatically (maybe only 32K ?) and would also save memory usage surely ?
>Fix:
Allow the configuration to build shared, archive or both types of libraries.
May need to re-link during the install in a similar way that GNU's libtool
has to. Only downer on this would be a slightly slower startup time for the
first httpd, but once the shared libraries are in memory, subsequent startup
times would be faster (though still a little slower than the .a versions).
Presumably there's some technical reason why httpd can't link against shared
library versions of its own code (can't think of one...), because this
suggestion sounds "way too obvious" to me otherwise !
>Audit-Trail:
>Unformatted:
[In order for any reply to be added to the PR database, ]
[you need to include <ap...@Apache.Org> in the Cc line ]
[and leave the subject line UNCHANGED.  This is not done]
[automatically because of the potential for mail loops. ]