On Fri, 24 May 2013 09:26:34 -0400 Jim Jagielski <j...@jagunet.com> wrote:
> > On May 24, 2013, at 9:08 AM, Jeff Trawick <traw...@gmail.com> 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; http://people.apache.org/~wrowe/httpd-2.2-ports/util_mutex.h http://people.apache.org/~wrowe/httpd-2.2-ports/mod_mutex.c 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 support. [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.
