You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Jan Kaluža <jk...@redhat.com> on 2013/07/09 12:16:33 UTC
[httpd24 branch] merge with trunk?
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
For additional commands, e-mail: dev-help@perl.apache.org
Re: [httpd24 branch] merge with trunk?
Posted by Jan Kaluza <jk...@redhat.com>.
----- Original Message -----
> Jan Kaluža wrote on 2013-07-11:
> > On 07/11/2013 10:41 AM, Steve Hay wrote:
> >> Jan Kaluža wrote on 2013-07-11:
> >>> On 07/11/2013 01:17 AM, Steve Hay wrote:
> >>>> 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.
> >>>
> >>
> >> I see that patch is in the httpd24 branch so it is already being
> >> done
> > on Windows just like any other OS, but the problem is that the path to
> > the library in question isn't known.
> >>
> >> In my build $libs is
> >>
> >> -LD:\temp\mp2\MODPER~1\blib\arch\auto\LIBAPR~1 -laprext -laprutil-1
> >>
> >> and libaprutil-l.lib is in D:\temp\mp2\apache\lib. If I manually add
> > -LD:\temp\mp2\apache\lib into $libs then it builds fine but I'm
> > struggling to automate that at the moment.
> >
> > Right, I had the same problem with automation and I decided to
> > hardcode it for Linux :(.
> >
>
> Where/how have you hard-coded the *path* to that library, though? I only see
> the library *name* hard-coded:
I don't, on Linux compiler has predefined paths where to find the libraries, so if the library is in that default path, it will be found.
Regards,
Jan Kaluza
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
RE: [httpd24 branch] merge with trunk?
Posted by Steve Hay <St...@verosoftware.com>.
Jan Kaluža wrote on 2013-07-11:
> On 07/11/2013 10:41 AM, Steve Hay wrote:
>> Jan Kaluža wrote on 2013-07-11:
>>> On 07/11/2013 01:17 AM, Steve Hay wrote:
>>>> 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.
>>>
>>
>> I see that patch is in the httpd24 branch so it is already being
>> done
> on Windows just like any other OS, but the problem is that the path to
> the library in question isn't known.
>>
>> In my build $libs is
>>
>> -LD:\temp\mp2\MODPER~1\blib\arch\auto\LIBAPR~1 -laprext -laprutil-1
>>
>> and libaprutil-l.lib is in D:\temp\mp2\apache\lib. If I manually add
> -LD:\temp\mp2\apache\lib into $libs then it builds fine but I'm
> struggling to automate that at the moment.
>
> Right, I had the same problem with automation and I decided to
> hardcode it for Linux :(.
>
Where/how have you hard-coded the *path* to that library, though? I only see the library *name* hard-coded:
# FIXME: This should be done automatically somewhere in Apache2::Build
$libs .= qq{ -laprutil-1 };
>> The httpd lib path that I need is seemingly available from
>> Apache2::BuildConfig:
>>
>> 'MODPERL_AP_LIBDIR' => 'D:\\temp\\mp2\\apache\\lib'
>>
>> but none of the MODPERL_* keys exist in the $build in
>> xs/APR/APR/Makefile.PL; they are presumably generated later.
>>
>>
>>>> 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.
>>>
[...]
>> So the problem here is that modperl_error.c is included in
> libaprext.lib, but it references the symbol "perl_module", which is
> defined in mod_perl.c, but that isn't included in libaprext.lib, so
> the symbol is unresolved when linking APR/Brigade.dll (and presumably
> any other APR/*.dll which links against libaprext.lib).
>>
>> Simply throwing mod_perl.c into libaprext.lib too doesn't work
> because it references many, many other symbols which are also not
> included.
>
>> So I think we need to move the definition of "perl_module" to some
> other file which either already is or else can be included in
> libaprext.lib, but I'm not sure where would be best right now.
>>
>
> I think moving it to different file is not possible. perl_module
> struct contains pointers to methods which later call another methods
> which really need all those symbols. So to define perl_module, you
> basically need all that stuff included in mod_perl.h.
>
> I think what you could do is to create dummy .c file and just add
> dummy perl_module definition there. No source code mentioned above (in
> libaprext.lib) actually needs perl_module, so it should be OK to do
> that. You wouldn't be able to use perl_module properly from external
> library anyway if I'm right.
>
> It's not ideal way, but I'm not sure I see better solution. I've done
> that in ModPerl::Const:
>
Ok, that sounds like a reasonable plan. I will look into later.
RE: [httpd24 branch] merge with trunk?
Posted by Steve Hay <St...@verosoftware.com>.
Jan Kaluža wrote on 2013-07-17:
>> t/api/server_const.t (Wstat: 512 Tests: 0 Failed: 0)
>> Non-zero exit status: 2 Parse errors: No plan found in TAP output
>> t/modules/apache_resource.t (Wstat: 512 Tests: 0 Failed:
>> 0) Non-zero exit status: 2 Parse errors: Bad plan. You planned 1
>> tests but ran 0.
>> t/modules/apache_status.t (Wstat: 65280 Tests: 0 Failed:
> 0)
>> Non-zero exit status: 255
>> Parse errors: Bad plan. You planned 15 tests but ran 0.
>
> Those are related to missing &Apache2::ServerUtil::get_server_version.
>
> You have removed that method in r1503137, because it's not provided by
> httpd-2.4, but there's compat method defined in
> modperl_apache_compat.h, which was used instead.
>
> I can fix the tests to use proper httpd-2.4 version and remove that
> compat version if it's problem on Windows. Or if you are going to link
> modules against modperl.lib on Windows, I think we could try reverting
> that commit, since I linking against modperl.lib would probably fix
> also this previous linking problem.
>
Thanks for pointing out my error in r1503137. That's now reverted and fixed properly by r1504043. I'd completely forgotten that we have a compat version of ap_get_server_version. We already link Apache2::* against mod_perl.lib, but the linker error was due to it not being exported from mod_perl.so, so it wasn't available for Apache2/ServerUtil/ServerUtil.dll to use.
Re: [httpd24 branch] merge with trunk?
Posted by Jan Kaluža <jk...@redhat.com>.
> t/api/server_const.t (Wstat: 512 Tests: 0 Failed: 0)
> Non-zero exit status: 2
> Parse errors: No plan found in TAP output
> t/modules/apache_resource.t (Wstat: 512 Tests: 0 Failed: 0)
> Non-zero exit status: 2
> Parse errors: Bad plan. You planned 1 tests but ran 0.
> t/modules/apache_status.t (Wstat: 65280 Tests: 0 Failed: 0)
> Non-zero exit status: 255
> Parse errors: Bad plan. You planned 15 tests but ran 0.
Those are related to missing &Apache2::ServerUtil::get_server_version.
You have removed that method in r1503137, because it's not provided by
httpd-2.4, but there's compat method defined in modperl_apache_compat.h,
which was used instead.
I can fix the tests to use proper httpd-2.4 version and remove that
compat version if it's problem on Windows. Or if you are going to link
modules against modperl.lib on Windows, I think we could try reverting
that commit, since I linking against modperl.lib would probably fix also
this previous linking problem.
Regards,
Jan Kaluza
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
RE: [httpd24 branch] merge with trunk?
Posted by Steve Hay <St...@verosoftware.com>.
Jan Kaluža wrote on 2013-07-17:
> On 07/16/2013 03:04 PM, Steve Hay wrote:
> The difference is that Apache2/Const/Const.dll now depends on
> mod_perl.so (it didn't use to), and that isn't in a location in the
> PATH when running the test suite.
>>
>> Using dumpbin /imports to see why we have this new dependency shows
> that it's due to the 'perl_module' symbol... We've been here before
> recently with the APR::Brigade build failure. I wondered if
> Apache2::Const (and maybe others) needed to link against libaprext.lib
> (with its fake 'perl_module' symbol) to avoid this problem, but
> lib/ModPerl/BuildMM says:
>>
>> # in order to decouple APR/APR::* from mod_perl.so, # link
>> these modules against the static MP_APR_LIB lib, # rather than
>> the mod_perl lib (which would demand mod_perl.so # be
>> available). For other modules, use mod_perl.lib as # usual.
>> which suggests that Apache2::* modules are expected to depend on
> mod_perl.so (even though this one happened not to until now), so using
> libaprext.lib instead of mod_perl.lib here is probably the wrong thing
> to do here and would likely break things that require a proper
> definitions of 'perl_module'.
>>
>> So I think the answer is to add src/modules/perl (where mod_perl.so has
>> been built) to the PATH when running the test suite.
>>
>> If I do that manually in my Command Prompt window then "nmake test"
> runs normally (albeit with a *lot* of test failures [1] which I'll
> look at later), but I'm not sure where is the best place to make that
> happen automatically within Apache-Test?
>>
>> Is this an issue on other OSes, or only on Windows? (Not sure if you
>> normally build mod_perl dynamically or statically linked elsewhere?)
>
> If I understand it right, we don't link modules to anything explicitly
> on Linux, but when they are loaded later, all their dependencies have
> to be loaded on runtime too. Since apr/apr-util and mod_perl are
> loaded by httpd, there's no problem.
>
> At least I see "LIBS => q[ ]" in MakeMaker parametrs for Apache2::*
> modules.
>
Ok. We definitely need to link against apr/apr-util and mod_perl libs on Windows to resolve symbols at link time, and that creates a demand for the corresponding DLLs (actually called .so rather than .dll) at run time.
All Apache2::* modules' DLLs have always been linked against the apr/apr-util and mod_perl libs (see ModPerl::BuildMM::WriteMakefile() -- isn't that used on other OSes too, though?), but the linker drops the dependency if no symbols are actually imported from them so in the past Apache2/Const/Const.dll didn't demand mod_perl.so at run time because it hadn't imported anything from it.
That's changed now, so I think I need to slip src/modules/perl into the PATH for testing. But I'm still puzzled why the demand to load mod_perl.so isn't already met, though, because httpd.exe must have already loaded it when it saw the LoadModule line in the conf file, which must be before anything mentions Apache2::Const. Httpd.exe, as you say, finds and loads mod_perl.so without problem (the LoadModule line in the test conf file contains a full path to it, for a start), so Apache2::Const's demand for it should just be a no-op, it being loaded already...
I will continue to investigate that before looking at changing Apache-Test. I wonder if something is using Apache2::Const too soon?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [httpd24 branch] merge with trunk?
Posted by Jan Kaluža <jk...@redhat.com>.
On 07/16/2013 03:04 PM, Steve Hay wrote:
> Jan Kaluža wrote on 2013-07-15:
>> On 07/15/2013 02:58 PM, Steve Hay wrote:
>>> [...] right now I still have it crashing
>> on startup (with or without revision r1303215), so we obviously didn't
>> have the same crashing problem after all :-/ I will try to fix that
>> next.
>>>
>>
>> I'm afraid I can't help you further here...
>>
>
> When running "nmake test" I'm getting:
>
> Can't load 'D:\temp\mp2d\modperl-httpd24\blib\arch/auto/Apache2/Const/Const.dll' for module Apache2::Const: load_file:The specified module could not be found at D:/temp/mp2d/perl/lib/DynaLoader.pm line 190.
> at D:\temp\mp2d\modperl-httpd24\t\response\TestApache\subprocess.pm line 13.
>
> Trying a simple one-liner:
>
> D:\temp\mp2d\perl\bin\perl.exe -Iblib\arch -Iblib\lib -MApache2::Const -e1
>
> does much the same. That works with trunk, built against httpd-2.2. The difference is that Apache2/Const/Const.dll now depends on mod_perl.so (it didn't use to), and that isn't in a location in the PATH when running the test suite.
>
> Using dumpbin /imports to see why we have this new dependency shows that it's due to the 'perl_module' symbol... We've been here before recently with the APR::Brigade build failure. I wondered if Apache2::Const (and maybe others) needed to link against libaprext.lib (with its fake 'perl_module' symbol) to avoid this problem, but lib/ModPerl/BuildMM says:
>
> # in order to decouple APR/APR::* from mod_perl.so,
> # link these modules against the static MP_APR_LIB lib,
> # rather than the mod_perl lib (which would demand mod_perl.so
> # be available). For other modules, use mod_perl.lib as
> # usual.
>
> which suggests that Apache2::* modules are expected to depend on mod_perl.so (even though this one happened not to until now), so using libaprext.lib instead of mod_perl.lib here is probably the wrong thing to do here and would likely break things that require a proper definitions of 'perl_module'.
>
> So I think the answer is to add src/modules/perl (where mod_perl.so has been built) to the PATH when running the test suite.
>
> If I do that manually in my Command Prompt window then "nmake test" runs normally (albeit with a *lot* of test failures [1] which I'll look at later), but I'm not sure where is the best place to make that happen automatically within Apache-Test?
>
> Is this an issue on other OSes, or only on Windows? (Not sure if you normally build mod_perl dynamically or statically linked elsewhere?)
If I understand it right, we don't link modules to anything explicitly
on Linux, but when they are loaded later, all their dependencies have to
be loaded on runtime too. Since apr/apr-util and mod_perl are loaded by
httpd, there's no problem.
At least I see "LIBS => q[ ]" in MakeMaker parametrs for Apache2::* modules.
>
> [1] The complete list of failures on this first run through (using a perl without LWP installed, so lots more tests were skipped too) is:
>
> Test Summary Report
> -------------------
> t\apache\subprocess.t (Wstat: 0 Tests: 1 Failed: 0)
> Parse errors: Bad plan. You planned 5 tests but ran 1.
> t\api\access2.t (Wstat: 0 Tests: 0 Failed: 0)
> Parse errors: No plan found in TAP output
> t\api\server_const.t (Wstat: 2304 Tests: 0 Failed: 0)
> Non-zero exit status: 9
> Parse errors: No plan found in TAP output
> t\apr-ext\brigade.t (Wstat: 1280 Tests: 0 Failed: 0)
> Non-zero exit status: 5
> Parse errors: Bad plan. You planned 14 tests but ran 0.
> t\apr-ext\bucket.t (Wstat: 1280 Tests: 0 Failed: 0)
> Non-zero exit status: 5
> Parse errors: Bad plan. You planned 21 tests but ran 0.
> t\apr-ext\finfo.t (Wstat: 1280 Tests: 0 Failed: 0)
> Non-zero exit status: 5
> Parse errors: Bad plan. You planned 27 tests but ran 0.
> t\apr-ext\perlio.t (Wstat: 1280 Tests: 0 Failed: 0)
> Non-zero exit status: 5
> Parse errors: No plan found in TAP output
> t\apr-ext\pool.t (Wstat: 1280 Tests: 0 Failed: 0)
> Non-zero exit status: 5
> Parse errors: Bad plan. You planned 77 tests but ran 0.
> t\apr-ext\table.t (Wstat: 1280 Tests: 0 Failed: 0)
> Non-zero exit status: 5
> Parse errors: Bad plan. You planned 58 tests but ran 0.
> t\apr-ext\threadmutex.t (Wstat: 1280 Tests: 0 Failed: 0)
> Non-zero exit status: 5
> Parse errors: Bad plan. You planned 5 tests but ran 0.
> t\apr-ext\threadrwlock.t (Wstat: 1280 Tests: 0 Failed: 0)
> Non-zero exit status: 5
> Parse errors: Bad plan. You planned 5 tests but ran 0.
> t\apr-ext\uri.t (Wstat: 1280 Tests: 0 Failed: 0)
> Non-zero exit status: 5
> Parse errors: Bad plan. You planned 36 tests but ran 0.
> t\compat\conn_rec.t (Wstat: 0 Tests: 2 Failed: 0)
> Parse errors: Bad plan. You planned 4 tests but ran 2.
> t\modperl\local_env.t (Wstat: 0 Tests: 6 Failed: 1)
> Failed test: 6
> t\modperl\merge.t (Wstat: 0 Tests: 10 Failed: 3)
> Failed tests: 3, 6, 9
> t\modperl\merge2.t (Wstat: 0 Tests: 10 Failed: 3)
> Failed tests: 3, 6, 9
> t\modperl\merge3.t (Wstat: 0 Tests: 10 Failed: 3)
> Failed tests: 3, 6, 9
> t\modperl\setupenv2.t (Wstat: 0 Tests: 23 Failed: 7)
> Failed tests: 17-23
> t\modules\cgi.t (Wstat: 0 Tests: 4 Failed: 4)
> Failed tests: 1-4
> t\modules\cgi2.t (Wstat: 0 Tests: 4 Failed: 4)
> Failed tests: 1-4
> t\modules\cgipost.t (Wstat: 0 Tests: 6 Failed: 5)
> Failed tests: 2-6
> t\modules\cgipost2.t (Wstat: 0 Tests: 6 Failed: 5)
> Failed tests: 2-6
> t\protocol\echo_block.t (Wstat: 0 Tests: 3 Failed: 2)
> Failed tests: 2-3
> t\protocol\echo_nonblock.t (Wstat: 0 Tests: 3 Failed: 1)
> Failed test: 2
> t\protocol\echo_timeout.t (Wstat: 0 Tests: 5 Failed: 4)
> Failed tests: 2-5
> t\protocol\pseudo_http.t (Wstat: 0 Tests: 13 Failed: 9)
> Failed tests: 3-8, 11-13
> Files=249, Tests=1937, 722 wallclock secs ( 2.12 usr + 0.30 sys = 2.42 CPU)
> Result: FAIL
> Failed 26/249 test programs. 51/1937 subtests failed.
>
That's my summary after the changes we've made:
t/api/access2.t (Wstat: 0 Tests: 0 Failed: 0)
Parse errors: No plan found in TAP output
t/api/server_const.t (Wstat: 512 Tests: 0 Failed: 0)
Non-zero exit status: 2
Parse errors: No plan found in TAP output
t/compat/conn_rec.t (Wstat: 0 Tests: 2 Failed: 0)
Parse errors: Bad plan. You planned 4 tests but ran 2.
t/modules/apache_resource.t (Wstat: 512 Tests: 0 Failed: 0)
Non-zero exit status: 2
Parse errors: Bad plan. You planned 1 tests but ran 0.
t/modules/apache_status.t (Wstat: 65280 Tests: 0 Failed: 0)
Non-zero exit status: 255
Parse errors: Bad plan. You planned 15 tests but ran 0.
t/modules/cgi.t (Wstat: 0 Tests: 5 Failed: 1)
Failed test: 3
t/modules/cgi2.t (Wstat: 0 Tests: 5 Failed: 2)
Failed tests: 1, 4
t/modules/cgipost.t (Wstat: 0 Tests: 6 Failed: 1)
Failed test: 5
t/modules/cgipost2.t (Wstat: 0 Tests: 6 Failed: 1)
Failed test: 5
t/modules/cgiupload.t (Wstat: 0 Tests: 2 Failed: 1)
Failed test: 2
Files=249, Tests=2754, 188 wallclock secs ( 1.38 usr 0.62 sys + 108.86
cusr 26.83 csys = 137.69 CPU)
- cgi*.t tests fails because of svn commit: r1491887 -
/perl/modperl/trunk/t/modperl/local_env.t.
- access2.t should not be run when compiled with 2.4, it contains
httpd-2.2 only code. access24.t is the same test rewritten for httpd-2.4.
- conn_rec.t does not work, because compat is not supported with
httpd-2.4. We would have to change remote_ip to cliet_ip in compat code,
but I haven't found out way how to make condition for that there.
I haven't examined other tests yet.
For comparison, following test summary is from mod_perl before Windows
related fixed. I will try to find out what changes make the tests to fail.
t/api/access2.t (Wstat: 0 Tests: 0 Failed: 0)
Parse errors: No plan found in TAP output
t/compat/conn_rec.t (Wstat: 0 Tests: 2 Failed: 0)
Parse errors: Bad plan. You planned 4 tests but ran 2.
t/modules/cgi.t (Wstat: 0 Tests: 5 Failed: 2)
Failed tests: 2, 5
t/modules/cgi2.t (Wstat: 0 Tests: 5 Failed: 1)
Failed test: 3
t/modules/cgipost.t (Wstat: 0 Tests: 6 Failed: 1)
Failed test: 4
t/modules/cgipost2.t (Wstat: 0 Tests: 6 Failed: 1)
Failed test: 4
t/modules/cgiupload.t (Wstat: 0 Tests: 2 Failed: 1)
Failed test: 1
t/modules/cgiupload2.t (Wstat: 0 Tests: 2 Failed: 1)
Failed test: 2
Regards,
Jan Kaluza
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
RE: [httpd24 branch] merge with trunk?
Posted by Steve Hay <St...@verosoftware.com>.
Jan Kaluža wrote on 2013-07-15:
> On 07/15/2013 02:58 PM, Steve Hay wrote:
>> [...] right now I still have it crashing
> on startup (with or without revision r1303215), so we obviously didn't
> have the same crashing problem after all :-/ I will try to fix that
> next.
>>
>
> I'm afraid I can't help you further here...
>
When running "nmake test" I'm getting:
Can't load 'D:\temp\mp2d\modperl-httpd24\blib\arch/auto/Apache2/Const/Const.dll' for module Apache2::Const: load_file:The specified module could not be found at D:/temp/mp2d/perl/lib/DynaLoader.pm line 190.
at D:\temp\mp2d\modperl-httpd24\t\response\TestApache\subprocess.pm line 13.
Trying a simple one-liner:
D:\temp\mp2d\perl\bin\perl.exe -Iblib\arch -Iblib\lib -MApache2::Const -e1
does much the same. That works with trunk, built against httpd-2.2. The difference is that Apache2/Const/Const.dll now depends on mod_perl.so (it didn't use to), and that isn't in a location in the PATH when running the test suite.
Using dumpbin /imports to see why we have this new dependency shows that it's due to the 'perl_module' symbol... We've been here before recently with the APR::Brigade build failure. I wondered if Apache2::Const (and maybe others) needed to link against libaprext.lib (with its fake 'perl_module' symbol) to avoid this problem, but lib/ModPerl/BuildMM says:
# in order to decouple APR/APR::* from mod_perl.so,
# link these modules against the static MP_APR_LIB lib,
# rather than the mod_perl lib (which would demand mod_perl.so
# be available). For other modules, use mod_perl.lib as
# usual.
which suggests that Apache2::* modules are expected to depend on mod_perl.so (even though this one happened not to until now), so using libaprext.lib instead of mod_perl.lib here is probably the wrong thing to do here and would likely break things that require a proper definitions of 'perl_module'.
So I think the answer is to add src/modules/perl (where mod_perl.so has been built) to the PATH when running the test suite.
If I do that manually in my Command Prompt window then "nmake test" runs normally (albeit with a *lot* of test failures [1] which I'll look at later), but I'm not sure where is the best place to make that happen automatically within Apache-Test?
Is this an issue on other OSes, or only on Windows? (Not sure if you normally build mod_perl dynamically or statically linked elsewhere?)
[1] The complete list of failures on this first run through (using a perl without LWP installed, so lots more tests were skipped too) is:
Test Summary Report
-------------------
t\apache\subprocess.t (Wstat: 0 Tests: 1 Failed: 0)
Parse errors: Bad plan. You planned 5 tests but ran 1.
t\api\access2.t (Wstat: 0 Tests: 0 Failed: 0)
Parse errors: No plan found in TAP output
t\api\server_const.t (Wstat: 2304 Tests: 0 Failed: 0)
Non-zero exit status: 9
Parse errors: No plan found in TAP output
t\apr-ext\brigade.t (Wstat: 1280 Tests: 0 Failed: 0)
Non-zero exit status: 5
Parse errors: Bad plan. You planned 14 tests but ran 0.
t\apr-ext\bucket.t (Wstat: 1280 Tests: 0 Failed: 0)
Non-zero exit status: 5
Parse errors: Bad plan. You planned 21 tests but ran 0.
t\apr-ext\finfo.t (Wstat: 1280 Tests: 0 Failed: 0)
Non-zero exit status: 5
Parse errors: Bad plan. You planned 27 tests but ran 0.
t\apr-ext\perlio.t (Wstat: 1280 Tests: 0 Failed: 0)
Non-zero exit status: 5
Parse errors: No plan found in TAP output
t\apr-ext\pool.t (Wstat: 1280 Tests: 0 Failed: 0)
Non-zero exit status: 5
Parse errors: Bad plan. You planned 77 tests but ran 0.
t\apr-ext\table.t (Wstat: 1280 Tests: 0 Failed: 0)
Non-zero exit status: 5
Parse errors: Bad plan. You planned 58 tests but ran 0.
t\apr-ext\threadmutex.t (Wstat: 1280 Tests: 0 Failed: 0)
Non-zero exit status: 5
Parse errors: Bad plan. You planned 5 tests but ran 0.
t\apr-ext\threadrwlock.t (Wstat: 1280 Tests: 0 Failed: 0)
Non-zero exit status: 5
Parse errors: Bad plan. You planned 5 tests but ran 0.
t\apr-ext\uri.t (Wstat: 1280 Tests: 0 Failed: 0)
Non-zero exit status: 5
Parse errors: Bad plan. You planned 36 tests but ran 0.
t\compat\conn_rec.t (Wstat: 0 Tests: 2 Failed: 0)
Parse errors: Bad plan. You planned 4 tests but ran 2.
t\modperl\local_env.t (Wstat: 0 Tests: 6 Failed: 1)
Failed test: 6
t\modperl\merge.t (Wstat: 0 Tests: 10 Failed: 3)
Failed tests: 3, 6, 9
t\modperl\merge2.t (Wstat: 0 Tests: 10 Failed: 3)
Failed tests: 3, 6, 9
t\modperl\merge3.t (Wstat: 0 Tests: 10 Failed: 3)
Failed tests: 3, 6, 9
t\modperl\setupenv2.t (Wstat: 0 Tests: 23 Failed: 7)
Failed tests: 17-23
t\modules\cgi.t (Wstat: 0 Tests: 4 Failed: 4)
Failed tests: 1-4
t\modules\cgi2.t (Wstat: 0 Tests: 4 Failed: 4)
Failed tests: 1-4
t\modules\cgipost.t (Wstat: 0 Tests: 6 Failed: 5)
Failed tests: 2-6
t\modules\cgipost2.t (Wstat: 0 Tests: 6 Failed: 5)
Failed tests: 2-6
t\protocol\echo_block.t (Wstat: 0 Tests: 3 Failed: 2)
Failed tests: 2-3
t\protocol\echo_nonblock.t (Wstat: 0 Tests: 3 Failed: 1)
Failed test: 2
t\protocol\echo_timeout.t (Wstat: 0 Tests: 5 Failed: 4)
Failed tests: 2-5
t\protocol\pseudo_http.t (Wstat: 0 Tests: 13 Failed: 9)
Failed tests: 3-8, 11-13
Files=249, Tests=1937, 722 wallclock secs ( 2.12 usr + 0.30 sys = 2.42 CPU)
Result: FAIL
Failed 26/249 test programs. 51/1937 subtests failed.
Re: [httpd24 branch] merge with trunk?
Posted by Jan Kaluža <jk...@redhat.com>.
On 07/15/2013 02:58 PM, Steve Hay wrote:
> Jan Kaluža wrote on 2013-07-15:
>> On 07/15/2013 12:52 PM, Steve Hay wrote:> Jan Kaluža wrote on 2013-07-
>> 15:
>>>> On 07/15/2013 12:30 PM, Steve Hay wrote:
>>>>> Jan Kaluža wrote on 2013-07-15:
>>>>>> On 07/15/2013 10:48 AM, Steve Hay wrote:
>>>>>>> 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.
>>>>>>
>>>>>
>>>>> That's good, actually, because it simultaneously means it isn't a
>>>>> Windows-only failure and greatly narrows down where the problem
>> must >>> be :-) >>> >>> I will look soon too if you haven't beaten
>> me to it ;-) >>> >> >> I think I have fixed that (together with
>> some compiler warnings) in >> r1503171. Hopefully it will still
>> compile properly on Windows. Please >> inform me if this revision
>> works for you. All expected tests are >> passing on Fedora in this
>> revision again.
>>>>
>>>
>>> At a quick glance I think it won't compile again because dTHXa and
>> dSP are declarations, which are now mixed up with code again.
>>
>> You are right. Maybe something like r1503193 could workaround that?
>> Although whole situation around that code is strange (see my FIXME
>> comment in the mentioned revision).
>>
>
> It now builds on Windows again.
>
> I've just rearranged it very slightly again in r1303215 to put back the early return if the key is not found, like you had done in r1503171. I've also protected the modperl_interp_pool_select() call and dTHXa() declaration with #ifdef USE_ITHREADS like other callers do.
It still works after these changes for me, so +1.
> Not sure what to say about the FIXME comment, but if modperl_interp_pool_select() can now return NULL then the other callers should test for that too, rather than always blindly dereferencing the return value.
>
> I will look at that shortly, but right now I still have it crashing on startup (with or without revision r1303215), so we obviously didn't have the same crashing problem after all :-/ I will try to fix that next.
>
I'm afraid I can't help you further here...
Regards,
Jan Kaluza
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
RE: [httpd24 branch] merge with trunk?
Posted by Steve Hay <St...@verosoftware.com>.
Jan Kaluža wrote on 2013-07-15:
> On 07/15/2013 12:52 PM, Steve Hay wrote:> Jan Kaluža wrote on 2013-07-
> 15:
>>> On 07/15/2013 12:30 PM, Steve Hay wrote:
>>>> Jan Kaluža wrote on 2013-07-15:
>>>>> On 07/15/2013 10:48 AM, Steve Hay wrote:
>>>>>> 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.
>>>>>
>>>>
>>>> That's good, actually, because it simultaneously means it isn't a
>>>> Windows-only failure and greatly narrows down where the problem
> must >>> be :-) >>> >>> I will look soon too if you haven't beaten
> me to it ;-) >>> >> >> I think I have fixed that (together with
> some compiler warnings) in >> r1503171. Hopefully it will still
> compile properly on Windows. Please >> inform me if this revision
> works for you. All expected tests are >> passing on Fedora in this
> revision again.
>>>
>>
>> At a quick glance I think it won't compile again because dTHXa and
> dSP are declarations, which are now mixed up with code again.
>
> You are right. Maybe something like r1503193 could workaround that?
> Although whole situation around that code is strange (see my FIXME
> comment in the mentioned revision).
>
It now builds on Windows again.
I've just rearranged it very slightly again in r1303215 to put back the early return if the key is not found, like you had done in r1503171. I've also protected the modperl_interp_pool_select() call and dTHXa() declaration with #ifdef USE_ITHREADS like other callers do.
Not sure what to say about the FIXME comment, but if modperl_interp_pool_select() can now return NULL then the other callers should test for that too, rather than always blindly dereferencing the return value.
I will look at that shortly, but right now I still have it crashing on startup (with or without revision r1303215), so we obviously didn't have the same crashing problem after all :-/ I will try to fix that next.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [httpd24 branch] merge with trunk?
Posted by Jan Kaluža <jk...@redhat.com>.
On 07/15/2013 12:52 PM, Steve Hay wrote:> Jan Kaluža wrote on 2013-07-15:
>> On 07/15/2013 12:30 PM, Steve Hay wrote:
>>> Jan Kaluža wrote on 2013-07-15:
>>>> On 07/15/2013 10:48 AM, Steve Hay wrote:
>>>>> 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.
>>>>
>>>
>>> That's good, actually, because it simultaneously means it isn't a
>>> Windows-only failure and greatly narrows down where the problem must
>>> be :-)
>>>
>>> I will look soon too if you haven't beaten me to it ;-)
>>>
>>
>> I think I have fixed that (together with some compiler warnings) in
>> r1503171. Hopefully it will still compile properly on Windows. Please
>> inform me if this revision works for you. All expected tests are
>> passing on Fedora in this revision again.
>>
>
> At a quick glance I think it won't compile again because dTHXa and
dSP are declarations, which are now mixed up with code again.
You are right. Maybe something like r1503193 could workaround that?
Although whole situation around that code is strange (see my FIXME
comment in the mentioned revision).
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
RE: [httpd24 branch] merge with trunk?
Posted by Steve Hay <St...@verosoftware.com>.
Jan Kaluža wrote on 2013-07-15:
> On 07/15/2013 12:30 PM, Steve Hay wrote:
>> Jan Kaluža wrote on 2013-07-15:
>>> On 07/15/2013 10:48 AM, Steve Hay wrote:
>>>> 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.
>>>
>>
>> That's good, actually, because it simultaneously means it isn't a
>> Windows-only failure and greatly narrows down where the problem must
>> be :-)
>>
>> I will look soon too if you haven't beaten me to it ;-)
>>
>
> I think I have fixed that (together with some compiler warnings) in
> r1503171. Hopefully it will still compile properly on Windows. Please
> inform me if this revision works for you. All expected tests are
> passing on Fedora in this revision again.
>
At a quick glance I think it won't compile again because dTHXa and dSP are declarations, which are now mixed up with code again.
Re: [httpd24 branch] merge with trunk?
Posted by Jan Kaluža <jk...@redhat.com>.
On 07/15/2013 12:30 PM, Steve Hay wrote:
> Jan Kaluža wrote on 2013-07-15:
>> On 07/15/2013 10:48 AM, Steve Hay wrote:
>>> 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.
>>
>
> That's good, actually, because it simultaneously means it isn't a Windows-only failure and greatly narrows down where the problem must be :-)
>
> I will look soon too if you haven't beaten me to it ;-)
>
I think I have fixed that (together with some compiler warnings) in
r1503171. Hopefully it will still compile properly on Windows. Please
inform me if this revision works for you. All expected tests are passing
on Fedora in this revision again.
Jan Kaluza
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
RE: [httpd24 branch] merge with trunk?
Posted by Steve Hay <St...@verosoftware.com>.
Jan Kaluža wrote on 2013-07-15:
> On 07/15/2013 10:48 AM, Steve Hay wrote:
>> 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.
>
That's good, actually, because it simultaneously means it isn't a Windows-only failure and greatly narrows down where the problem must be :-)
I will look soon too if you haven't beaten me to it ;-)
Re: [httpd24 branch] merge with trunk?
Posted by Jan Kaluža <jk...@redhat.com>.
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-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org
>
Regards,
Jan Kaluza
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
RE: [httpd24 branch] merge with trunk?
Posted by Steve Hay <St...@verosoftware.com>.
Jan Kaluža wrote on 2013-07-15:
> 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.
>
> This looks great, but shouldn't ap_provider.h be guarded by #ifdef? I
> think this header does not exist before 2.4.
Oops! Thanks for the spot. Fixed in r1503154.
Re: [httpd24 branch] merge with trunk?
Posted by Jan Kaluža <jk...@redhat.com>.
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.
This looks great, but shouldn't ap_provider.h be guarded by #ifdef? I
think this header does not exist before 2.4.
> The first fix might be the key to how to resolve that "FIXME" in xs/APR/APR/Makefile.PL?
I will try to build latest httpd24 branch HEAD in Fedora and see if it
fixes it too.
>
>>
>> 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-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
RE: [httpd24 branch] merge with trunk?
Posted by Steve Hay <St...@verosoftware.com>.
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-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
RE: [httpd24 branch] merge with trunk?
Posted by Steve Hay <St...@verosoftware.com>.
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).
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?
Re: [httpd24 branch] merge with trunk?
Posted by Steve Hay <st...@googlemail.com>.
On 11 July 2013 14:33, Steve Hay <St...@verosoftware.com> wrote:
>
> Jan Kaluža wrote on 2013-07-11:
> > On 07/11/2013 11:06 AM, Jan Kaluža wrote:
> >>> So the problem here is that modperl_error.c is included in
> >>> libaprext.lib, but it references the symbol "perl_module", which is
> >>> defined in mod_perl.c, but that isn't included in libaprext.lib, so
> >>> the symbol is unresolved when linking APR/Brigade.dll (and presumably
> >>> any other APR/*.dll which links against libaprext.lib).
> >>>
[...]
> >> I think what you could do is to create dummy .c file and just add dummy
> >> perl_module definition there. No source code mentioned above (in
> >> libaprext.lib) actually needs perl_module, so it should be OK to do
> >> that. You wouldn't be able to use perl_module properly from external
> >> library anyway if I'm right.
> >>
> >> It's not ideal way, but I'm not sure I see better solution. I've
> >> done that in ModPerl::Const:
> >>
> >> http://jkaluza.fedorapeople.org/mod_perl/0023-Define-perl_module-in- Co
> >> nst.xs.patch
> >
> > When thinking about it, it's really strange we have problems with
> > perl_module in httpd24 branch, because that part of code didn't change
> > at all in httpd24 branch.
> >
> > In trunk, the perl_module in mod_perl.h is declared as extern too and
> > the files used to link libaprext.lib are also the same. Maybe there
> > are different compler/linker flags in use when building with 2.4
> > causing this behaviour?
> >
> > I think that could be worth checking too.
> >
>
> The problem arises from code in modperl_apache_compat.h which applies only to httpd-2.4 builds, but which is already committed to trunk:
>
> #if AP_SERVER_MAJORVERSION_NUMBER>2 || \
> (AP_SERVER_MAJORVERSION_NUMBER == 2 && AP_SERVER_MINORVERSION_NUMBER>=3)
>
> /* 2.4 API */
> ...
> #define mp_module_index_ perl_module.module_index,
>
> #else
> /* 2.2 API */
> ...
> #define mp_module_index_
>
> #endif /* 2.4 vs. 2.2 API */
>
> Unless you can think of anything that we can change/move in that code then I'll pursue your idea of a dummy .c file with a dummy definition of perl_module.
That works a treat, so I've now done that in r1502392.
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).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
RE: [httpd24 branch] merge with trunk?
Posted by Steve Hay <St...@verosoftware.com>.
Jan Kaluža wrote on 2013-07-11:
> On 07/11/2013 11:06 AM, Jan Kaluža wrote:
>>> So the problem here is that modperl_error.c is included in
>>> libaprext.lib, but it references the symbol "perl_module", which is
>>> defined in mod_perl.c, but that isn't included in libaprext.lib, so
>>> the symbol is unresolved when linking APR/Brigade.dll (and presumably
>>> any other APR/*.dll which links against libaprext.lib).
>>>
>>> Simply throwing mod_perl.c into libaprext.lib too doesn't work
>>> because it references many, many other symbols which are also not
> included.
>>
>>> So I think we need to move the definition of "perl_module" to some
>>> other file which either already is or else can be included in
>>> libaprext.lib, but I'm not sure where would be best right now.
>>>
>>
>> I think moving it to different file is not possible. perl_module
>> struct contains pointers to methods which later call another methods
>> which really need all those symbols. So to define perl_module, you
>> basically need all that stuff included in mod_perl.h.
>>
>> I think what you could do is to create dummy .c file and just add dummy
>> perl_module definition there. No source code mentioned above (in
>> libaprext.lib) actually needs perl_module, so it should be OK to do
>> that. You wouldn't be able to use perl_module properly from external
>> library anyway if I'm right.
>>
>> It's not ideal way, but I'm not sure I see better solution. I've
>> done that in ModPerl::Const:
>>
>> http://jkaluza.fedorapeople.org/mod_perl/0023-Define-perl_module-in- Co
>> nst.xs.patch
>
> When thinking about it, it's really strange we have problems with
> perl_module in httpd24 branch, because that part of code didn't change
> at all in httpd24 branch.
>
> In trunk, the perl_module in mod_perl.h is declared as extern too and
> the files used to link libaprext.lib are also the same. Maybe there
> are different compler/linker flags in use when building with 2.4
> causing this behaviour?
>
> I think that could be worth checking too.
>
The problem arises from code in modperl_apache_compat.h which applies only to httpd-2.4 builds, but which is already committed to trunk:
#if AP_SERVER_MAJORVERSION_NUMBER>2 || \
(AP_SERVER_MAJORVERSION_NUMBER == 2 && AP_SERVER_MINORVERSION_NUMBER>=3)
/* 2.4 API */
...
#define mp_module_index_ perl_module.module_index,
#else
/* 2.2 API */
...
#define mp_module_index_
#endif /* 2.4 vs. 2.2 API */
Unless you can think of anything that we can change/move in that code then I'll pursue your idea of a dummy .c file with a dummy definition of perl_module.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [httpd24 branch] merge with trunk?
Posted by Jan Kaluža <jk...@redhat.com>.
On 07/11/2013 11:06 AM, Jan Kaluža wrote:
>> The error is:
>>
>> libaprext.lib(modperl_error.obj) : error LNK2001: unresolved external
>> symbol _perl_module
>> ..\..\..\blib\arch\auto\APR\Brigade\Brigade.dll : fatal error LNK1120:
>> 1 unresolved externals
>>
>> On Windows we build a static library called libaprext.lib containing
>> various symbols otherwise found in mod_perl.lib/dll for APR DLLs to
>> link against so that they don't have a dependency on mod_per.dll --
>> see the comments in the top-level Makefile.PL around line 187.
>>
>> The list of source files whose objects are put in this library (given
>> by ModPerl::Code::src_apr_ext()) is:
>>
>> modperl_error.c
>> modperl_bucket.c
>> modperl_common_util.c
>> modperl_common_log.c
>>
>> So the problem here is that modperl_error.c is included in
>> libaprext.lib, but it references the symbol "perl_module", which is
>> defined in mod_perl.c, but that isn't included in libaprext.lib, so
>> the symbol is unresolved when linking APR/Brigade.dll (and presumably
>> any other APR/*.dll which links against libaprext.lib).
>>
>> Simply throwing mod_perl.c into libaprext.lib too doesn't work because
>> it references many, many other symbols which are also not included.
>
>> So I think we need to move the definition of "perl_module" to some
>> other file which either already is or else can be included in
>> libaprext.lib, but I'm not sure where would be best right now.
>>
>
> I think moving it to different file is not possible. perl_module struct
> contains pointers to methods which later call another methods which
> really need all those symbols. So to define perl_module, you basically
> need all that stuff included in mod_perl.h.
>
> I think what you could do is to create dummy .c file and just add dummy
> perl_module definition there. No source code mentioned above (in
> libaprext.lib) actually needs perl_module, so it should be OK to do
> that. You wouldn't be able to use perl_module properly from external
> library anyway if I'm right.
>
> It's not ideal way, but I'm not sure I see better solution. I've done
> that in ModPerl::Const:
>
> http://jkaluza.fedorapeople.org/mod_perl/0023-Define-perl_module-in-Const.xs.patch
When thinking about it, it's really strange we have problems with
perl_module in httpd24 branch, because that part of code didn't change
at all in httpd24 branch.
In trunk, the perl_module in mod_perl.h is declared as extern too and
the files used to link libaprext.lib are also the same. Maybe there are
different compler/linker flags in use when building with 2.4 causing
this behaviour?
I think that could be worth checking too.
>
> Regards,
> Jan Kaluza
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
> For additional commands, e-mail: dev-help@perl.apache.org
>
Regards,
Jan Kaluza
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [httpd24 branch] merge with trunk?
Posted by Jan Kaluža <jk...@redhat.com>.
On 07/11/2013 10:41 AM, Steve Hay wrote:
> Jan Kaluža wrote on 2013-07-11:
>> On 07/11/2013 01:17 AM, Steve Hay wrote:
>>> 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.
>>
>
> I see that patch is in the httpd24 branch so it is already being done on Windows just like any other OS, but the problem is that the path to the library in question isn't known.
>
> In my build $libs is
>
> -LD:\temp\mp2\MODPER~1\blib\arch\auto\LIBAPR~1 -laprext -laprutil-1
>
> and libaprutil-l.lib is in D:\temp\mp2\apache\lib. If I manually add -LD:\temp\mp2\apache\lib into $libs then it builds fine but I'm struggling to automate that at the moment.
Right, I had the same problem with automation and I decided to hardcode
it for Linux :(.
> The httpd lib path that I need is seemingly available from Apache2::BuildConfig:
>
> 'MODPERL_AP_LIBDIR' => 'D:\\temp\\mp2\\apache\\lib'
>
> but none of the MODPERL_* keys exist in the $build in xs/APR/APR/Makefile.PL; they are presumably generated later.
>
>
>>> 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.
>>
>
> The error is:
>
> libaprext.lib(modperl_error.obj) : error LNK2001: unresolved external symbol _perl_module
> ..\..\..\blib\arch\auto\APR\Brigade\Brigade.dll : fatal error LNK1120: 1 unresolved externals
>
> On Windows we build a static library called libaprext.lib containing various symbols otherwise found in mod_perl.lib/dll for APR DLLs to link against so that they don't have a dependency on mod_per.dll -- see the comments in the top-level Makefile.PL around line 187.
>
> The list of source files whose objects are put in this library (given by ModPerl::Code::src_apr_ext()) is:
>
> modperl_error.c
> modperl_bucket.c
> modperl_common_util.c
> modperl_common_log.c
>
> So the problem here is that modperl_error.c is included in libaprext.lib, but it references the symbol "perl_module", which is defined in mod_perl.c, but that isn't included in libaprext.lib, so the symbol is unresolved when linking APR/Brigade.dll (and presumably any other APR/*.dll which links against libaprext.lib).
>
> Simply throwing mod_perl.c into libaprext.lib too doesn't work because it references many, many other symbols which are also not included.
> So I think we need to move the definition of "perl_module" to some other file which either already is or else can be included in libaprext.lib, but I'm not sure where would be best right now.
>
I think moving it to different file is not possible. perl_module struct
contains pointers to methods which later call another methods which
really need all those symbols. So to define perl_module, you basically
need all that stuff included in mod_perl.h.
I think what you could do is to create dummy .c file and just add dummy
perl_module definition there. No source code mentioned above (in
libaprext.lib) actually needs perl_module, so it should be OK to do
that. You wouldn't be able to use perl_module properly from external
library anyway if I'm right.
It's not ideal way, but I'm not sure I see better solution. I've done
that in ModPerl::Const:
http://jkaluza.fedorapeople.org/mod_perl/0023-Define-perl_module-in-Const.xs.patch
Regards,
Jan Kaluza
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
RE: [httpd24 branch] merge with trunk?
Posted by Steve Hay <St...@verosoftware.com>.
Jan Kaluža wrote on 2013-07-11:
> On 07/11/2013 01:17 AM, Steve Hay wrote:
>> 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.
>
I see that patch is in the httpd24 branch so it is already being done on Windows just like any other OS, but the problem is that the path to the library in question isn't known.
In my build $libs is
-LD:\temp\mp2\MODPER~1\blib\arch\auto\LIBAPR~1 -laprext -laprutil-1
and libaprutil-l.lib is in D:\temp\mp2\apache\lib. If I manually add -LD:\temp\mp2\apache\lib into $libs then it builds fine but I'm struggling to automate that at the moment.
The httpd lib path that I need is seemingly available from Apache2::BuildConfig:
'MODPERL_AP_LIBDIR' => 'D:\\temp\\mp2\\apache\\lib'
but none of the MODPERL_* keys exist in the $build in xs/APR/APR/Makefile.PL; they are presumably generated later.
>> 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.
>
Thanks, now committed in r1502135.
>> 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.
>
The error is:
libaprext.lib(modperl_error.obj) : error LNK2001: unresolved external symbol _perl_module
..\..\..\blib\arch\auto\APR\Brigade\Brigade.dll : fatal error LNK1120: 1 unresolved externals
On Windows we build a static library called libaprext.lib containing various symbols otherwise found in mod_perl.lib/dll for APR DLLs to link against so that they don't have a dependency on mod_per.dll -- see the comments in the top-level Makefile.PL around line 187.
The list of source files whose objects are put in this library (given by ModPerl::Code::src_apr_ext()) is:
modperl_error.c
modperl_bucket.c
modperl_common_util.c
modperl_common_log.c
So the problem here is that modperl_error.c is included in libaprext.lib, but it references the symbol "perl_module", which is defined in mod_perl.c, but that isn't included in libaprext.lib, so the symbol is unresolved when linking APR/Brigade.dll (and presumably any other APR/*.dll which links against libaprext.lib).
Simply throwing mod_perl.c into libaprext.lib too doesn't work because it references many, many other symbols which are also not included.
So I think we need to move the definition of "perl_module" to some other file which either already is or else can be included in libaprext.lib, but I'm not sure where would be best right now.
Re: [httpd24 branch] merge with trunk?
Posted by Jan Kaluža <jk...@redhat.com>.
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 <jkaluza@redhat.com
> <ma...@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
> <ma...@perl.apache.org>
> For additional commands, e-mail: dev-help@perl.apache.org
> <ma...@perl.apache.org>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [httpd24 branch] merge with trunk?
Posted by Steve Hay <st...@googlemail.com>.
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...
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.
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.
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?
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.
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
On 9 July 2013 11:16, Jan Kaluža <jk...@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<de...@perl.apache.org>
> For additional commands, e-mail: dev-help@perl.apache.org
>
>