httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject RE: cvs commit: apache-2.0/src ApacheCoreDll.dsp Apache.dspApacheCore.dsp Apache.dsw ApacheCore.def
Date Tue, 06 Jun 2000 03:07:27 GMT
> > >     Fixes 1) The htpasswd and ab binaries, by converting
> ApacheCore.dsp to
> > >              a library MSVC project.
> > >
> > >           2) Creates the ApacheCoreDll.dsp project to
> produce the dso
> > >              version ApacheCore.dll
> > >
> > >           3) Some misc fixups to the original http_main.c
> -> Apache.exe
> > >              conversion that misses newly added symbols.
> > >
> > >     Code fixes to follow in a seperate patch.
> >
> > Ok... if there are objections, let 'em fly.  The Win32
> Apache-2.0 port should
> > now build and run.  There are still some flukes (I'm
> chasing a GP fault right
> > now, but it may not even be in the 'real' code, but in my
> development tree :-)
> I still don't see why we need .lib and .dll versions of our code. Just
> create .dll versions and dynamic-link against them. The additional
> complexity of two types of outputs seems rather silly... what is the
> benefit that we get?

Simple, small binaries that load quickly, without any extra .dll's to
bind to.  I want to put htdigest in my /winnt/bin folder, then I just
move it without trying to lug around a horribly transient .dll (that
will change weekly :-)  ab is worse, you in theory throw it on a floppy
and walk it around your lab to beat up on your server.

Today Apache.exe, aprlib.dll and ApacheCore.dll sit in the root of the
apache installation.  The modules sit in the modules/ tree, but the
modules they link to (aprlib/ApacheCore) were loaded before in the
address space.

htpasswd.exe and ab.exe sit in the bin/ tree.  They can't find their
way home to their dll's :-)  It strikes me as less of a waste to build
a lib, then link the objects into a .dll, than to keep copies of all
our dll's proliferated across the installation tree.

We compile only once.  The side effect is that the silly .exe exports
symbols for it's bound functions.  Do we really care?

> > Unix DSO Question:
> >
> > I was reading over the dso docs for Unix.  They imply we set up a stub when
> > we are building the dso library version of the unix port.
> What is "the dso library version of the unix port" ?
> From the rest of your email, it seems like you are under the impression
> that Apache can be built as a .so. Euh... not the case. As a result, there
> are no main() issues.

Then I misunderstood this article...


Although this DSO mechanism sounds straightforward there is at least one difficult step here:
The resolving of symbols from the
executable program for the DSO when using a DSO to extend a program (the second way). Why?
Because "reverse resolving" DSO symbols
from the executable program's symbol set is against the library design (where the library
has no knowledge about the programs it is
used by) and is neither available under all platforms nor standardized. In practice the executable
program's global symbols are
often not re-exported and thus not available for use in a DSO. Finding a way to force the
linker to export all global symbols is the
main problem one has to solve when using DSO for extending a program at run-time.


As of Apache 1.3, the configuration system supports two optional features for taking advantage
of the modular DSO approach:
compilation of the Apache core program into a DSO library for shared usage and compilation
of the Apache modules into DSO files for
explicit loading at run-time.

View raw message