Hi.
I'm a php developer, and I'm using VC9 php builds on windows(PHP 5.3 doesn't
support ), hence I'm using the apache httpd builds from apachelounge.com,
because you guys only offer VC6 windows builds, and I'm too lazy to build
myself.
My question is: why is this the case? as far as I can tell,
Hi
If I remember correctly wrowe said it was because a lot of 3rd party
modules use VC6.
Although that was a while ago so I could be wrong.
If I'm indeed correct maybe 2.4 is a good time to switch to VC9?
~Jorge
On Mon, Jan 31, 2011 at 10:06 AM, Ferenc Kovacs tyr...@gmail.com wrote:
Hi.
Hi.
thanks for the reply.
does that mean that you can either support/provide the VC6 OR the VC9
builds, but not both?
that seems weird to me, but thats your call.
if thats the only way to add support for the VC9 builds, then +1 for the
switch in the 2.4, but I would guess that is years from
On 31 Jan 2011, at 09:39, Ferenc Kovacs wrote:
does that mean that you can either support/provide the VC6 OR the VC9 builds,
but not both?
Providing any kind of binaries is not Apache's business.
Third-parties like apachelounge do that.
Why does it matter what the binary is built with?
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.
Issac
On 31/01/2011 11:21, Jorge Schrauwen wrote:
Hi
If I remember
On Mon, Jan 31, 2011 at 10:54 AM, Nick Kew n...@webthing.com wrote:
On 31 Jan 2011, at 09:39, Ferenc Kovacs wrote:
does that mean that you can either support/provide the VC6 OR the VC9
builds, but not both?
Providing any kind of binaries is not Apache's business.
Third-parties like
Right, command line builds where part of the reason for still using
VC6. Alteast that rings a vague bell.
If we provide VC9 builds for 2.4+, we could do a 32-bit and 64-bit one then...
But that would mean 3 (or 2) binary packages for windows which
could result in a lot of extra work :(
How
Only wrowe knows how, I think. I vaguely remembering volunteering to
help make them, and us coming to a mutual conclusion that it'd be more
effort to set up the env for me, than it would be long-term help for me
to have it (this was for VC6, and partially because VC6 isn't available
on MSDN
On 01/31/2011 11:54 AM, Ferenc Kovacs wrote:
On Mon, Jan 31, 2011 at 10:54 AM, Nick Kew n...@webthing.com
mailto:n...@webthing.com wrote:
On 31 Jan 2011, at 09:39, Ferenc Kovacs wrote:
does that mean that you can either support/provide the VC6 OR the VC9
builds, but not both?
On 1/31/2011 3:21 AM, Jorge Schrauwen wrote:
Hi
If I remember correctly wrowe said it was because a lot of 3rd party
modules use VC6.
Although that was a while ago so I could be wrong.
If I'm indeed correct maybe 2.4 is a good time to switch to VC9?
There are a host of reasons we never
On 1/31/2011 5:00 AM, Issac Goldstand wrote:
Only wrowe knows how, I think. I vaguely remembering volunteering to
help make them, and us coming to a mutual conclusion that it'd be more
effort to set up the env for me, than it would be long-term help for me
to have it (this was for VC6, and
Hi,
I have a requirement to merge multiple response Via headers, if any. Can this
be achieved using the 'Header merge Via' option? Apparently, it needs a value
to merge with, since I get this error: Header requires three arguments.
Is there any way to achieve this through configuration?
On 01/31/2011 04:34 PM, William A. Rowe Jr. wrote:
There are a host of reasons we never supported MSVCRn where n is an
arbitrary value modified by Microsoft on a biannual basis.
But indeed, at 2.4 we will be shipping to the then-shipping crt, not
vc9.
And the winner would be?
Regards
--
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
Hi Raj,
I have a requirement to merge multiple response Via headers, if any. Can this
be achieved using the 'Header merge Via' option? Apparently, it needs a value
to merge with, since I get this error: Header requires three arguments.
Is there any way to achieve this through
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
On 1/31/2011 9:41 AM, Mladen Turk wrote:
On 01/31/2011 04:34 PM, William A. Rowe Jr. wrote:
There are a host of reasons we never supported MSVCRn where n is an
arbitrary value modified by Microsoft on a biannual basis.
But indeed, at 2.4 we will be shipping to the then-shipping crt, not
On 31/01/2011 17:36, 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 1/31/2011 11:52 AM, Issac Goldstand wrote:
On 31/01/2011 17:36, 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
On 01/31/2011 06:20 PM, William A. Rowe Jr. wrote:
On 1/31/2011 9:55 AM, Mladen Turk wrote:
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
On 1/31/2011 12:17 PM, Mladen Turk wrote:
On 01/31/2011 06:20 PM, William A. Rowe Jr. wrote:
On 1/31/2011 9:55 AM, Mladen Turk wrote:
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
On 01/31/2011 07:33 PM, William A. Rowe Jr. wrote:
On 1/31/2011 12:17 PM, Mladen Turk wrote:
If we resist on using CRT stuff like strcpy_l/strcpy_s, _fstat64i32 and
other weirdness from contemporary CRTs, we'd be fine.
Actually most of those date back to msvcrt.dll or have been added over
On Mon, Jan 31, 2011 at 3:28 PM, j...@apache.org wrote:
Author: jim
Date: Mon Jan 31 20:28:52 2011
New Revision: 1065748
URL: http://svn.apache.org/viewvc?rev=1065748view=rev
Log:
Move some nice to be able to change balancer stuff to shm
Modified:
httpd/httpd/trunk/configure.in
...
On 1/31/2011 3:39 PM, Jeff Trawick wrote:
On Mon, Jan 31, 2011 at 3:28 PM, j...@apache.org wrote:
Author: jim
Date: Mon Jan 31 20:28:52 2011
New Revision: 1065748
--- httpd/httpd/trunk/configure.in (original)
+++ httpd/httpd/trunk/configure.in Mon Jan 31 20:28:52 2011
@@ -529,7 +529,7 @@
http://people.apache.org/~phred/Apache-Test-1.36-rc1.tar.gz
+1 on OS X and Linux. Last release before mod_perl 2.0.5.
Skip sok.t unless perlio is enabled [Torsten Foertsch]
Deprecate t/TEST -times=X in favor of t/SMOKE -times=X. Changes to
TAP::Harness have removed the ability to re-use test
25 matches
Mail list logo
