httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: official httpd VC9 builds
Date Mon, 31 Jan 2011 17:20:03 GMT
On 1/31/2011 9:55 AM, Mladen Turk wrote:
> On 01/31/2011 04:36 PM, William A. Rowe Jr. wrote:
>> On 1/31/2011 4:05 AM, Issac Goldstand wrote:
>>> I believe also that wrowe mentioned to me that  we wanted to support
>>> command line (make) builds, and VC9 doesn't allow us to export makefiles.
>>>
>>> I'm +1 for making both VC6 and VC9 builds from 2.4 and on, like PHP does.
>>
>> In this case, your +1 means you are offering to do so :)
>>
>> Binaries are built by whichever committers feel like building binaries, period.
>>
>> I have no interest in VC9, it's already stale.  At least if we pick up the
>> then-shipping flavor as of 2.4.0, we stand to win by sticking with that
>> specific version to the end of the 2.4 lifespan.
>>
> 
> There is a solution to use DDK7.1
> It can create binaries that links to MSVCRT, however
> this works for XP+ only.

Which works... provided we continue on the makefile approach or use msbuild.
Note that openssl encourages exactly this solution, and goes out of their way
to avoid msvcrXX flavors.

There are now other reasons to avoid msvcrt.dll, given that the maintainers
have declared msvcrt to be an OS component, and have declined to track C
standards or portability.  This is evidenced in their handling of *printf
family of functions, which PHP folks have tripped over in awkward ways, and
found no satisfaction reporting the issues to MS.

VC9 is irrelevant since it was already replaced by Studio 2010 (which I believe
is studio 10.0, the studio 2008 was studio 9.0, bundling VC 15.0, not 9, which
distributes MSVC*90.dll components.  Confusing, eh?).

Studio 2010/MSVC*100.dll components SP1 rev is now in beta.  Given how quickly
the 2.4.0 release is progressing, I'm betting I'll ship MSVC*100.dll based
components when all is said and done with 2.4.0.

Note none of this is germane to the actual request, for two reasons.  One,
there should be no reason that httpd and apr need to have a matching rev
level of msvcr unless you are playing with the underlying os objects, e.g.
using the apr_os_* functions.  Now finding cooperation with things like
zlib, openssl etc can be frustrating, because some of these libraries may
like to exchange malloc'ed buffers for the caller to destroy, or msvcr
pseudo-posix file handles (which aren't win32 HANDLE objects), etc.  If any
such objects are created, consumed and destroyed in one library, it should
not matter that the object is linked to msvcrXX, while the app is linked
to msvcrYY.  It might be sub-optimal at load time, but it shouldn't be
destructive.  I'll give you a concrete example, mod_aspdotnet was bound to
the studio .net (2002 flavor) in order to use C++.net 1.0.  It loads and
runs in an msvcrt.dll based httpd server with no issues at all, although it
only uses msvcr71.dll itself.

If anyone notices apr or httpd exchanging such resources in a way that would
make httpd crash, we would *love* to know about it!  This is the time for us
to complete any corrections to the API, before httpd 2.4 ships.

The other reason is that there is a bunch of work going on at the CoApp project
(not at the ASF, but at http://coapp.org) which should lead to binaries of
httpd, php and the like which are all set up using SXS assemblies of consistent
libraries, binaries packages which they intend to ship and maintain just as
debian or freebsd or any other linux packager would do.  Accommodating MS's
schizophrenic approaches to library interoperability really shouldn't be part
of httpd's or php's headaches, any more than dealing with the distinctions
which RedHat/SuSE/Debian all introduce for their linux distributions.






Mime
View raw message