Re: svn commit: r1622429 - /httpd/httpd/branches/2.4.x/STATUS

2014-09-04 Thread Ruediger Pluem
Can we really backport this? We are increasing the size of proxy_worker_shared and changing offsets inside the struct. Regards Rüdiger rj...@apache.org wrote: Author: rjung Date: Thu Sep 4 09:21:16 2014 New Revision: 1622429 URL: http://svn.apache.org/r1622429 Log: Propose.

Re: svn commit: r1622429 - /httpd/httpd/branches/2.4.x/STATUS

2014-09-04 Thread Rainer Jung
Am 04.09.2014 um 12:13 schrieb Ruediger Pluem: Can we really backport this? We are increasing the size of proxy_worker_shared and changing offsets inside the struct. Bummer, I guess you are right. mod_proxy.h seems to be part of the public API so we can't backport like this. Will revoke the

Re: C99 bump prior to apr 2.0?

2014-09-04 Thread Wang, Andy
Is there a reason to not bundle the msvcrtxxx.dll that's microsoft includes in the redist area? So that's what we've taken to doing with our apache. Simply including the version that microsoft bundles with 2010 in the web server bin directory. Thanks, Andy On Wed, 2014-09-03 at 17:52 -0500,

Re: C99 bump prior to apr 2.0?

2014-09-04 Thread Issac Goldstand
You can't, AFAIK, due to licensing. You need to include the *installer* that comes in VC's redist area and can run that installer from yours to install their runtime... Or you can statically link to the runtime, but I'm not sure we want to do that. On 04/09/2014 17:48, Wang, Andy wrote: Is

RE: Re: C99 bump prior to apr 2.0?

2014-09-04 Thread wrowe
You can do this. However, that doesn't solve the problem for users of one distribution of httpd (from any origin, not just the ASF) linked to a particular msvcr###, interoperating with a module built by another third party for a different msvcr### (or trying to build your own add-in with a

RE: Re: C99 bump prior to apr 2.0?

2014-09-04 Thread wrowe
- Original Message - Subject: Re: C99 bump prior to apr 2.0? From: Wang, Andy aw...@ptc.com Date: 9/4/14 9:48 am To: dev@httpd.apache.org dev@httpd.apache.org Is there a reason to not bundle the msvcrtxxx.dll that's microsoft includes in the redist area? So that's what we've

Re: C99 bump prior to apr 2.0?

2014-09-04 Thread William A. Rowe Jr.
I overlooked 2 other viable options [ ] Roll -win32-src-r2.zip with apr-util 1.5.2 (pre-breakage) and corresponding binaries [ ] Roll -win32-src-r2.zip with apr-util 1.5.4 (upon release) and corresponding binaries wr...@rowe-clan.net wrote: Finally returned to VC6, having replaced my older

Re: C99 bump prior to apr 2.0?

2014-09-04 Thread Wang, Andy
According to: http://msdn.microsoft.com/en-us/library/8kche8ah.aspx And the redist.txt file in the Visual Studio Redist directory: For your convenience, we have provided the following folders for use when redistributing VC++ runtime files. Subject to the license terms for the software, you may

Re: Re: C99 bump prior to apr 2.0?

2014-09-04 Thread Wang, Andy
Good point. I'd forgotten about compatibility with third party modules. That said, by arbitrarily selecting VC6 aren't you also stuck with the same problem? Thanks, Andy On Thu, 2014-09-04 at 08:33 -0700, wr...@rowe-clan.net wrote: You can do this. However, that doesn't solve the problem for

Re: Re: C99 bump prior to apr 2.0?

2014-09-04 Thread Wang, Andy
I picked 2010 because it's what I have :) But that's sort of the point of my question. Why pick something so old as VC6 and not something newer, and hopefully better. FYI, I'm not complaining or nit-picking. I'm a complete newbie hack at Windows development and trying to understand the train

Re: C99 bump prior to apr 2.0?

2014-09-04 Thread Gregg Smith
On 9/4/2014 8:49 AM, William A. Rowe Jr. wrote: I overlooked 2 other viable options [ ] Roll -win32-src-r2.zip with apr-util 1.5.2 (pre-breakage) and corresponding binaries [ ] Roll -win32-src-r2.zip with apr-util 1.5.4 (upon release) and corresponding binaries Assumes a much quicker path

Re: svn commit: r1622429 - /httpd/httpd/branches/2.4.x/STATUS

2014-09-04 Thread Jim Jagielski
As long as we bump mmn, we should be OK. On Sep 4, 2014, at 6:13 AM, Ruediger Pluem rpl...@apache.org wrote: Can we really backport this? We are increasing the size of proxy_worker_shared and changing offsets inside the struct. Regards Rüdiger rj...@apache.org wrote: Author:

Re: svn commit: r1622429 - /httpd/httpd/branches/2.4.x/STATUS

2014-09-04 Thread Jim Jagielski
I think we can, as long as we bump the MMN... On Sep 4, 2014, at 7:22 AM, Rainer Jung rainer.j...@kippdata.de wrote: Am 04.09.2014 um 12:13 schrieb Ruediger Pluem: Can we really backport this? We are increasing the size of proxy_worker_shared and changing offsets inside the struct.

AW: svn commit: r1622429 - /httpd/httpd/branches/2.4.x/STATUS

2014-09-04 Thread Plüm , Rüdiger , Vodafone Group
But IMHO that would be a major bump and not a minor one. And we cannot do major ones in stable branches. Regards Rüdiger -Ursprüngliche Nachricht- Von: Jim Jagielski [mailto:j...@jagunet.com] Gesendet: Donnerstag, 4. September 2014 19:55 An: dev@httpd.apache.org Betreff: Re: svn

Re: svn commit: r1622429 - /httpd/httpd/branches/2.4.x/STATUS

2014-09-04 Thread Jim Jagielski
On Sep 4, 2014, at 6:13 AM, Ruediger Pluem rpl...@apache.org wrote: Can we really backport this? We are increasing the size of proxy_worker_shared and changing offsets inside the struct. True, but if we bump the mmn, that should cover it. I know of no-one other than httpd that uses

AW: svn commit: r1622429 - /httpd/httpd/branches/2.4.x/STATUS

2014-09-04 Thread Plüm , Rüdiger , Vodafone Group
-Ursprüngliche Nachricht- Von: Jim Jagielski Gesendet: Donnerstag, 4. September 2014 19:58 An: dev@httpd.apache.org Betreff: Re: svn commit: r1622429 - /httpd/httpd/branches/2.4.x/STATUS On Sep 4, 2014, at 6:13 AM, Ruediger Pluem rpl...@apache.org wrote: Can we really

Re: svn commit: r1622429 - /httpd/httpd/branches/2.4.x/STATUS

2014-09-04 Thread Jim Jagielski
I think, in this case, a minor could be justified. On Sep 4, 2014, at 1:57 PM, Plüm, Rüdiger, Vodafone Group ruediger.pl...@vodafone.com wrote: But IMHO that would be a major bump and not a minor one. And we cannot do major ones in stable branches. Regards Rüdiger -Ursprüngliche

Re: svn commit: r1622429 - /httpd/httpd/branches/2.4.x/STATUS

2014-09-04 Thread Jim Jagielski
Agreed all the way around... PS: I *think* we also did this before, when we needed to bump up some *scoreboard* field sizes (to support IPv6) and we still did it w/ a minor bump, iirc. On Sep 4, 2014, at 2:02 PM, Plüm, Rüdiger, Vodafone Group ruediger.pl...@vodafone.com wrote:

Re: svn commit: r1622429 - /httpd/httpd/branches/2.4.x/STATUS

2014-09-04 Thread William A. Rowe Jr.
No... only if the patch is restructured to preserve all existing structure members at their current offsets. New struct members at the end of an existing structure is the definition of a minor mmn bump. If third party module authors allocate ap structs, it is their job to track against mmn