You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Steve Hay <St...@verosoftware.com> on 2013/08/02 19:10:08 UTC
RE: [httpd24 branch] apr-ext crashes
Steve Hay wrote on 2013-07-30:
> It's actually only the path to mod_perl.so that I need to add to the
> PATH, which I'd determined previously was due to the new dependency (now
> in ModPerl/Const/Const.dll) on mod_perl.so for the perl_module symbol.
>
> I'll look at that again, or else just work around it for now by adding
> to the PATH in the top-level Makefile.PL's MY::test().
>
For the record, I have now committed that "workaround" in rev. 1509781 after deciding that it's fine, not just a nasty hack. The commit message hopefully describes my reasoning adequately:
"Add the path to mod_perl.so to the PATH when running the test suite on Windows
Httpd.exe is able to find mod_perl.so because the test httpd.conf contains a LoadModule line with the fully qualified path to mod_perl.so in it. However, before httpd.exe is started the test framework must create that httpd.conf file. In the case of mod_perl it uses perl.exe and goes into Apache/TestConfigPerl.pm's run_apache_test_configure(), which runs APACHE_TEST_CONFIGURE() in various modules in t/response/TestApache (e.g. subprocess.pm). Those modules all use Apache2::Const, but Apache2/Const/Const.dll and ModPerl/Const/Const.dll now depend on mod_perl.so for the 'perl_module' symbol. Therefore, perl.exe must be able to find mod_perl.so when running the tests, and this is the easiest way to achieve that.
There is no problem with Apache2::Const and ModPerl::Const depending on mod_perl.so because they are normally only used within a mod_perl application, which will (obviously) have mod_perl.so loaded already. (It is only the APR::* modules which we are at pains (elsewhere) to avoid having a dependency on mod_perl.so because they are of use outside of mod_perl applications.)"
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [httpd24 branch] apr-ext crashes
Posted by Jan Kaluža <jk...@redhat.com>.
On 08/02/2013 07:10 PM, Steve Hay wrote:
> Steve Hay wrote on 2013-07-30:
>> It's actually only the path to mod_perl.so that I need to add to the
>> PATH, which I'd determined previously was due to the new dependency (now
>> in ModPerl/Const/Const.dll) on mod_perl.so for the perl_module symbol.
>>
>> I'll look at that again, or else just work around it for now by adding
>> to the PATH in the top-level Makefile.PL's MY::test().
>>
>
> For the record, I have now committed that "workaround" in rev. 1509781 after deciding that it's fine, not just a nasty hack. The commit message hopefully describes my reasoning adequately:
>
> "Add the path to mod_perl.so to the PATH when running the test suite on Windows
>
> Httpd.exe is able to find mod_perl.so because the test httpd.conf contains a LoadModule line with the fully qualified path to mod_perl.so in it. However, before httpd.exe is started the test framework must create that httpd.conf file. In the case of mod_perl it uses perl.exe and goes into Apache/TestConfigPerl.pm's run_apache_test_configure(), which runs APACHE_TEST_CONFIGURE() in various modules in t/response/TestApache (e.g. subprocess.pm). Those modules all use Apache2::Const, but Apache2/Const/Const.dll and ModPerl/Const/Const.dll now depend on mod_perl.so for the 'perl_module' symbol. Therefore, perl.exe must be able to find mod_perl.so when running the tests, and this is the easiest way to achieve that.
>
> There is no problem with Apache2::Const and ModPerl::Const depending on mod_perl.so because they are normally only used within a mod_perl application, which will (obviously) have mod_perl.so loaded already. (It is only the APR::* modules which we are at pains (elsewhere) to avoid having a dependency on mod_perl.so because they are of use outside of mod_perl applications.)"
>
That makes sense. I have also tested httpd24 branch again and it's still
working as expected for me.
Jan Kaluza
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org