On 07/11/2013 01:17 AM, Steve Hay wrote:
Hi Jan,
Thank you so much for all your work on this!
>
I've finally got round to having a look at it (sorry it's been so
long!), and have run into some teething problems here on Windows...
Thank you for trying that branch. I haven't actually tried to compile it
on Windows.
The first problem was "Warning (mostly harmless): No library found for
-laprutil-1" appearing from Makefile.PL between ModPerl::WrapXS and APR
(presumably it applies to the latter), which I've ignored for now but
will probably come back to bite me later. No other such issues are
reported, and all the libraries (apr-1.lib, aprutil-1.lib, libapr-1.lib,
libapriconv-1.lib, libaprutil-1.lib, libhttpd.lib, mod_dav.lib and
xml.lib) are together in C:\Apache24\lib, so I'm not sure what the
problem is there yet.
After thinking about that for a bit and checking all my patches I've
found out there's the same problem on Linux. I have overcame that with
quite hardcoded way last year when trying to get it work:
http://jkaluza.fedorapeople.org/mod_perl/0020-Link-APR.so-against-libaprutil-1.patch
Something like that is probably needed on Windows too. Proper way would
be to fix Apache2::Build to include this library, but I was not able to
achieve that last year if I remember well.
Next up, modperl_util.c contained various declarations scatted amongst
code which VC++ doesn't support when compiling C (rather than C++). I've
fixed that in r1502045.
Right, that was really bug. Thanks for fixing that.
Next, modperl_apache_compat.c complains that we're *defining* the
missing httpd function "ap_get_server_version", but we've declared it
the same way as httpd would do -- that is, marked "dllexport" when
compiled in httpd and otherwise marked "dllimport" to say that we're
third-party code importing it from httpd. We're third-party code, of
course, but *defining* a function marked "dllimport" isn't allowed.
Removing dllexport/dllimport from the declaration (see attached patch)
fixes this for me, but I don't know if that's the right thing on other OSes?
It works for me. It does not change XS generation, it builds and tests
are working. Feel free to commit that patch to httpd24.
The build now progress to APR::Brigade, but falls over complaining that
modperl_error.c references the symbol "perl_module", but that isn't
defined anywhere.
Can you send full compiler error? perl_module should be declared in
mod_perl.h and defined in mod_perl.c.
I've had similar issue when building xs/ModPerl/Const. That was caused
by ModPerl::Const using mod_perl.h, but did not compiling mod_perl.c, so
extern perl_module variable was not defined. Maybe there's similar
situation in Windows for some file too.
I would check full trace which leads you to undefined perl_module and
check if files have #include mod_perl.h and links with compiler's
mod_perl.c output.
I've run out of time tonight but will come back to this very soon. If
you can shed any light on the remaining problems so far that might
assist me when I look again then please let me know.
Steve
Regards,
Jan Kaluza
On 9 July 2013 11:16, Jan Kaluža <jkal...@redhat.com
<mailto:jkal...@redhat.com>> wrote:
Hi,
I just want to say that from my point of view, it should be possible
to merge httpd24 branch with trunk now. Maybe it's time to actually
do the merge and give that code some more testing.
Before future release, we have to coordinate with Apache-Test to
release also new Apache-Test which contains fixes needed to run
mod_perl with httpd24.
I'm going to update mod_perl to the HEAD of httpd24 branch in Fedora
soon too to give it more testing.
Regards,
Jan Kaluza
------------------------------__------------------------------__---------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.__org
<mailto:dev-unsubscr...@perl.apache.org>
For additional commands, e-mail: dev-h...@perl.apache.org
<mailto:dev-h...@perl.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org
For additional commands, e-mail: dev-h...@perl.apache.org
