On 07/15/2013 10:48 AM, Steve Hay wrote:
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...
It crashed for me too here. It used to work before the changes you've
done in last week. I will review them and try to find out what's wrong.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
For additional commands, e-mail: dev-h...@perl.apache.org
Regards,
Jan Kaluza
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
For additional commands, e-mail: dev-h...@perl.apache.org
