httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <>
Subject Re: Symbol Resolution (Was: Whither Windows (Was: Re: Intent to revert commit r1332643))
Date Fri, 24 May 2013 15:13:48 GMT
On Fri, 24 May 2013 09:26:34 -0400
Jim Jagielski <> wrote:

> On May 24, 2013, at 9:08 AM, Jeff Trawick <> wrote:
> > 
> > Lots of us are employees of or otherwise manage to siphon money
> > from these companies.  Make a pitch...  (And some of us are happy
> > to freelance ;) )
> I'll be honest: I don't even know to to *build* for Windows,
> at least with any Visual Studio release from this century.

That fortunately is documented, with some pretty good notes in
the wiki as well that aught to percolate into the docs.  That
said, documenting every Microsoft-version-quirk seems out of
scope for a general purpose 'compiling' doc.

Symbol resolution on Linux is rather loosey-goosey, and very
relaxed.  Resolution in OS/X 2-level namespace mode is quite
strict and a very good mirror of the world of Windows, z/OS and
many others[1].  It should be relatively easy to enforce explicit
exports on some other platforms which more of the developers
use in day-to-day practice.

The patch to 'fix' this is trivial.  The well-documented issues
with that 'fix' is the reason this patch should be reverted.

httpd has a reasonably straightforward pattern to register
and consume optional functions, hook functions etc.  This has
existed since close to the dawn of 2.0 and /had/ resolved almost
all module load-ordering issues in the server software.  It was
close to world-class in behavior and quite foolproof when the
return codes were observed.  To see how simple these are in
practice, see my backport of the Mutex behavior for 2.4-based 
modules to borrow when compiled under 2.2;

Optional hooks were introduced to allow for the registration of 
a sometimes-present, sometimes absent hook provider because not 
every hook was relevant to the core httpd server and not every
hook should always exist.  Both proxy and dav are good examples
of modules which must introduce new hooks themselves.

This patch ignored that, and introduced a hook provider that now
exists in a sometimes-loaded module which the core is looking
to register in.  It breaks the pattern because that hook is not
an optional hook.  The implementation is a mess and it has been
documented for a year what would fix it to follow httpd convention.

The much greater problem is that the current proxy provider stack
is riddled with load-time linkage between proxy modules, rather
than run-time optional functions and hooks.  This means that the
entire LoadModule mod_proxy schema is broken and fails to follow
the design principals of httpd 2.0.

How can developers without Windows possibly cope with identifying
these problems?  Magically, all it takes is to re-sort your
LoadModule list in inverse order and see what breaks.  There are
very few "Windows-only" behaviors in the server that can't be
documented with some trivial tests even on Linux.

So unless we really no longer care about this 'enhancement' to
the Apache 2.0 family, it seems past time to start re-factoring
such newly-reintroduced fragile behaviors and come back to that
design principal.  Or perhaps chuck it and go back to hard module
linkages and document the required load orders?  That would save
a few ms at startup.

It seems that we would all benefit from working out the libtool
and exports.c logic so that we can have some explicit-export model 
on Linux that will approximate windows and demonstrate this logic 
to those who don't (and shouldn't have to) build on Windows, WDYT?

p.s. I think your prior thread is rather dismissive of Gregg,
and folks like Steffan who go out of their way to follow these
docs and regularly report problems on Windows.  It's dismissive
of folks like Jeff and the rest who untangled the thorny change
in mod_ssl that broke the windows MPM preloaded socket data
approach so badly.  The fact that reports and objections are 
ignored does not mean the platform is ignored.  This is the only 
major issue I am aware of, nobody seems to have problems generating 
builds outside of the ASF, and we haven't seemed to have a large 
issue of following the Subversion model of binaries.

p.p.s. We have delivered 2.0 and 2.2 binaries and aught to update
those, now that my VM's are healed with the necessary crazy MSVCRT
based compilation environment the 'final' 2.0 binary can be built
and a refresh of 2.2 can be provided.  (Mladen's hybrid solution 
rocks, but there are some insane to workaround quirks for httpd 
with his solution that weren't present in building apr, -util etc).

p.p.p.s. I'll build a demonstration 2.4 package over the holiday
weekend, but don't consider it 'prime time' just yet.  We have a 
ways to go before all the Windows' players concerns can be resolved,
I'll put up a scratchpad in the wiki for us to discuss.  Lua et al
introduce more 3rd-party build questions than they answer.

p.p.p.p.s. Note that the Lua project makes life difficult for ALL
packagers, leaving shared lua libs entirely up to the packager and
offering no build support at all for that model.  Compare this to
httpd today which simply builds, with some initial file conversion
or ./configure'ation right out of the tarball with shared module

[1] Note OS/X 2-level namespace allows 2 different versions of a
    similar library, e.g. openldap and netscape ldap to coexist in
    memory at the same time, much as the MS Windows DLL behavior
    demonstrates. I don't advocate that we need to enforce that
    level of complexity.  Exporting only explicit symbols in a
    single-level namespace based on _DECLARE macros would be
    perfectly sufficient to catch 99% of issues.

View raw message