httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <>
Subject Re: Draft proposal: Win32 Compilation Environment Step 1
Date Mon, 17 Apr 2000 14:34:51 GMT
I completely agree that we should NOT put aprlib.dll into winnt/system32.  +1 on blasting
the makefiles, provided it is very easy to regen them when using VC++ 5. I am ambivilant
about whether APR is a dll or is statically linked into Apache.  We definitely
should -not- attempt to support multiple applications each accessing the same dll (with
perhaps one exception, the support routines that ship with Apache could/should use the
common APR dll). The one requirement we do have is that the exported symbol ordinals do
not change when a new function or variable is added to then exported from APR.  We don't
want to require Apache module authors to recompile their modules because someone adds new
functions to APR, but does not change the interface of any of the existing functions the
module depends on.

> Step 2 will build an apr.lib from the apr.dsp/apr.mak project files
> which mirrors the aprlib.  But it will become a STATIC library,
> for those applications that call for it. Namely, support applications.
> Here's where I am absolutely jammed.  Now I know why I created
> that apr.dsp 4 project library...
> We don't want aprlib.dll in winnt/system32 since it's a moving
> target.


> So what do we want?
> ??? A second copy of aprlib.dll in support?
>     That's rather sad.
> ??? Continue to compile the apr sources within support apps?
>     That's just nuts.


> ??? Have both apr and aprlib declare all the sources?  This
>     looks like a headache.


> ??? Have apr build a lib with the export symbols defined,
>     have aprlib turn that lib into a dll, and continue
>     to use the apr.lib with symbols to link to static exe's?
>     Just some wasted space, if I am correct, or perhaps I
>     can throw away the export table from the linker.

I think this would be perfectly acceptable.

> ??? Go to the idea of "Win32 Static" projects, as I've
>     proposed once before?

Never quite had a handle on this.

View raw message