Steffen, unfortunately not. They now contains changes that only compile with a 2.4.21 httpd.
-Stefan > Am 14.06.2016 um 11:06 schrieb Steffen <i...@apachelounge.com>: > > I rather like to test before tagging. > > Can you apply these changes for my testing also to Git ? > > Steffen > > On Tuesday 14/06/2016 at 10:54, Stefan Eissing wrote: >> I just backported the h2_proxy_util.c change in r1748359. It also uses the >> back ported ap_cstr_casecmp* instead of its own copies. I tried to update >> the win build files appropriately, but am unable to check the correctness. >> >> Gregg: please commit your changes when awake enough. Hopefully Jim can keep >> his fingers from the tag button long enough... >> >> Cheers, >> >> Stefan >> >>> Am 13.06.2016 um 22:40 schrieb William A Rowe Jr <wr...@rowe-clan.net>: >>> >>> On Mon, Jun 13, 2016 at 1:59 PM, Gregg Smith <g...@gknw.net> wrote: >>> I have the to connect this module in the traditional windows build but as >>> of right now it's using h2_util.c which Bill had an objection to. See his >>> comments http://marc.info/?l=apache-httpd-dev&m=146543811201820&w=2 >>> >>> So to me that seems to be a -1 to mod_proxy_http2, at minimum on Windows. >>> In trunk Stefan seems to have chosen option 3 in Bill's list and that is >>> h2_proxy_util.c. >>> >>> If I knew that was going to be backported I would add the rest of the bits >>> needed to use h2_proxy_util.c. If it is not going to make it, then I will >>> not commit anything and there will be no mod_proxy_http2 in 2.4.21 on >>> Windows. If this gets in overnight and you tag in the morning, I may not be >>> out of bed yet due to the time difference. >>> >>> That's where my concern is. Make sense? >>> >>> Shouldn't be a concern. I'm mildly concerned about the single-level >>> namespace >>> collisions on Unix, but because the .so object is pre-linked to its own >>> functions >>> before anything is imported/exported, mod_http2.so should be using >>> h2_utils.o >>> and mod_proxy_http2.so should be using h2_proxy_utils.o, even without any >>> additional namespace protection. A third module trying to use the functions >>> of >>> those two modules could cause headaches, but that can be addressed later. >>> >>> Windows has two-level namespaces, so there is no ambiguity between symbols >>> in one .so (.dll) and a second, unless you are simultaneously linking a >>> module >>> to both of these modules. >>> >>> I accept Stefan's proposed fix for the time being, and we can certainly make >>> this simpler on trunk in the future. >>> >>> Cheers, >>> >>> Bill >>> >>> >> > >
