Steve Hay wrote on 2013-07-12: > Steve Hay wrote on 2013-07-12: >> The problem of how to specify the path of aprutil-1 in >> xs/APR/APR/Makefile.PL remains, but with the fix above the build now >> proceeds to the next problem: Apache2/Provider.dll fails to link, >> with an unresolved external symbol, ap_register_provider. >> >> That symbol is exported from libhttpd.dll so I'm not sure right now >> why the link fails because we *do* already link against libhttpd.lib >> (and it has found it, along with libapr-1.lib and libaprutil-1.lib, >> this time). > > I've temporarily dodged the two problems above by (a) commenting out > the addition of -laprutil-1 to $libs in xs/APR/APR/Makefile.PL until I > figure out how to get its path, and (b) disabling the XS-wrapping of > ap_register_provider (by adding a leading '!' character) in > xs/maps/apache2-functions.map (it was only being wrapped for httpd > > 2.3.0, but I can't figure out what causes it not to link at the moment).
I've now fixed those two problems properly in r1503135 and r1503136 respectively. The first fix might be the key to how to resolve that "FIXME" in xs/APR/APR/Makefile.PL? > > So that got things going a little further. I've fixed some more code > before declaration errors in Apache2__RequestUtil.h (r1502464) but now > I've got another linker error, this time in Apache2/ServerUtil.dll: it > complains that ap_get_server_version is unresolved, and this time the > error is genuine. The symbol was exported from libhttpd.dll in httpd- > 2.2, but ap_mmn.h notes that it was replaced with ap_get_server_banner > and ap_get_server_description in httpd-2.3 so I think I need to add > some more #_if_ ... #_end_ magic to apache2_functions.map to account > for that. > > The attached patch does this, and with that in place the build now > runs through to completion (so perhaps the -laprutil-1 commented out > as mentioned above isn't even needed on Windows anyway? -- unless some > problem with omitting it comes to light in due course then I will just > make it conditional on !WIN32...). > > What puzzles me is how can the build be working on other OSes? This > one is definitely not a Windows-specific problem. Before I go ahead > and commit this patch, is there some part of the puzzle that I'm missing? > How does it build for others without the patch? I've committed that too in r1503137. It's easily reverted if it causes trouble for anyone, and we're only working on a branch here anyway. So I now have a build of mod_perl against httpd-2.4. Yay! However, it doesn't run yet... it's crashing when starting up the server. I will look into that very soon... --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org For additional commands, e-mail: dev-h...@perl.apache.org
