On Mon, Jun 13, 2016 at 1:59 PM, Gregg Smith <[email protected]> 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
