You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Randy Kobes <ra...@theoryx5.uwinnipeg.ca> on 2003/04/19 18:44:18 UTC
Re: finding mod_perl shared object on win32
On Mon, 31 Mar 2003, Stas Bekman wrote:
> Randy Kobes wrote:
> > On Fri, 28 Mar 2003, Stas Bekman wrote:
> >>Randy,
> >>
> >>I've looked at this issue and I don't see this problem on
> >>linux. Admittedly there was a problem with using -apxs which
> >>was finding mod_perl.so when it wasn't supposed to, which
> >>I've fixed now in cvs.
> >>
> >>Currently the logic goes like this (at this moment only
> >>relevant to mod_perl 2.0 built as DSO):
> >>
> >>1. always ignore the whatever 'LoadModule perl_module path'
> >>was found in global httpd.conf (that's what pre_configure()
> >>does)
> >>
> >>2. look at the build config options, if such exists (which is
> >>the case when mod_perl was installed on the system or we are
> >>inside the core build), use the information from there
> >>
> >>3. otherwise die, saying oops, mod_perl is not installed
[ ... ]
Hi Stas,
I think I've figured out why this wasn't working for
me (having Apache-Test load the installed mod_perl.so for a 3rd
party module) - I'm doing this for a Perl where mod_perl 2 isn't
installed (I'm just making Apache-Test available), so the
build config options isn't available.
I guess this case is only a problem when using Apache 1.3.
What about calling pre_configure() only if Apache 2.0 is being
used, as in the following:
==========================================================
Index: TestRun.pm
===================================================================
RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.105
diff -u -r1.105 TestRun.pm
--- TestRun.pm 27 Mar 2003 22:19:30 -0000 1.105
+++ TestRun.pm 19 Apr 2003 16:48:20 -0000
@@ -560,13 +560,14 @@
$self->getopts(\@argv);
- $self->pre_configure() if $self->can('pre_configure');
-
$self->{test_config} = $self->new_test_config;
- $self->warn_core();
-
$self->{server} = $self->{test_config}->server;
+
+ $self->pre_configure()
+ if ($self->can('pre_configure') && $self->{server}->{version} !~ /1.3/);
+
+ $self->warn_core();
local($SIG{__DIE__}, $SIG{INT});
$self->install_sighandlers;
=======================================================================
I think this should only affect building 3rd party modules
with Apache 1.3, as things should have died long before this
if trying to build mod_perl 2 with Apache 1.3.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: finding mod_perl shared object on win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Tue, 22 Apr 2003, Stas Bekman wrote:
[ .. ]
> > Understood. How about this patch:
> >
> > Index: Apache-Test/lib/Apache/TestRunPerl.pm
> > ===================================================================
> > RCS file:
> > /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRunPerl.pm,v
> > retrieving revision 1.10
> > diff -u -r1.10 TestRunPerl.pm
> > --- Apache-Test/lib/Apache/TestRunPerl.pm 26 Jan 2003 03:14:04
> > -0000 1.10
> > +++ Apache-Test/lib/Apache/TestRunPerl.pm 21 Apr 2003 03:53:53 -0000
> > @@ -14,8 +14,12 @@
> > sub pre_configure {
> > my $self = shift;
> >
> > - Apache::TestConfig::config_parse_skip_module_add('mod_perl.c');
> > -
> > + # don't pick up 'LoadModule ... mod_perl.so' from the global
> > + # httpd.conf, when using the locally built .so in the tests
> > + if (eval { require mod_perl } && $mod_perl::VERSION >= 1.99 &&
> > + eval {require Apache::Build} &&
> > Apache::Build::IS_MOD_PERL_BUILD()) {
> > + Apache::TestConfig::config_parse_skip_module_add('mod_perl.c');
> > + }
> > }
> >
> > sub configure_modperl {
> >
> >
> > since this long conditional is already used elsewhere in Apache::Test
> > should probably refactor it as an Apache::TestConfig::IS_MOD_PERL2_BUILD
> > constant.
>
> I'm still not happy about it. It needs more work to handle
> correctly mod_perl 1.0. Meanwhile please check the attached
> patch (against the current cvs).
Thanks, Stas, and sorry for the delay - we have a mini-crisis
at work here ... I'll check this out tonight.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: finding mod_perl shared object on win32
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Randy Kobes wrote:
>
>> On Mon, 31 Mar 2003, Stas Bekman wrote:
>>
>>
>>> Randy Kobes wrote:
>>>
>>>> On Fri, 28 Mar 2003, Stas Bekman wrote:
>>>
>>>
>>
>>>>> Randy,
>>>>>
>>>>> I've looked at this issue and I don't see this problem on
>>>>> linux. Admittedly there was a problem with using -apxs which
>>>>> was finding mod_perl.so when it wasn't supposed to, which
>>>>> I've fixed now in cvs.
>>>>>
>>>>> Currently the logic goes like this (at this moment only
>>>>> relevant to mod_perl 2.0 built as DSO):
>>>>>
>>>>> 1. always ignore the whatever 'LoadModule perl_module path'
>>>>> was found in global httpd.conf (that's what pre_configure()
>>>>> does)
>>>>>
>>>>> 2. look at the build config options, if such exists (which is
>>>>> the case when mod_perl was installed on the system or we are
>>>>> inside the core build), use the information from there
>>>>>
>>>>> 3. otherwise die, saying oops, mod_perl is not installed
>>>>
>>>>
>> [ ... ]
>>
>> Hi Stas,
>> I think I've figured out why this wasn't working for
>> me (having Apache-Test load the installed mod_perl.so for a 3rd party
>> module) - I'm doing this for a Perl where mod_perl 2 isn't
>> installed (I'm just making Apache-Test available), so the build config
>> options isn't available.
>> I guess this case is only a problem when using Apache 1.3.
>> What about calling pre_configure() only if Apache 2.0 is being
>> used, as in the following:
>> ==========================================================
>> Index: TestRun.pm
>> ===================================================================
>> RCS file:
>> /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
>> retrieving revision 1.105
>> diff -u -r1.105 TestRun.pm
>> --- TestRun.pm 27 Mar 2003 22:19:30 -0000 1.105
>> +++ TestRun.pm 19 Apr 2003 16:48:20 -0000
>> @@ -560,13 +560,14 @@
>>
>> $self->getopts(\@argv);
>>
>> - $self->pre_configure() if $self->can('pre_configure');
>> -
>> $self->{test_config} = $self->new_test_config;
>>
>> - $self->warn_core();
>> -
>> $self->{server} = $self->{test_config}->server;
>> +
>> + $self->pre_configure() + if ($self->can('pre_configure')
>> && $self->{server}->{version} !~ /1.3/);
>> +
>> + $self->warn_core();
>>
>> local($SIG{__DIE__}, $SIG{INT});
>> $self->install_sighandlers;
>> =======================================================================
>> I think this should only affect building 3rd party modules with Apache
>> 1.3, as things should have died long before this if trying to build
>> mod_perl 2 with Apache 1.3.
>
>
> Understood. How about this patch:
>
> Index: Apache-Test/lib/Apache/TestRunPerl.pm
> ===================================================================
> RCS file:
> /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRunPerl.pm,v
> retrieving revision 1.10
> diff -u -r1.10 TestRunPerl.pm
> --- Apache-Test/lib/Apache/TestRunPerl.pm 26 Jan 2003 03:14:04
> -0000 1.10
> +++ Apache-Test/lib/Apache/TestRunPerl.pm 21 Apr 2003 03:53:53 -0000
> @@ -14,8 +14,12 @@
> sub pre_configure {
> my $self = shift;
>
> - Apache::TestConfig::config_parse_skip_module_add('mod_perl.c');
> -
> + # don't pick up 'LoadModule ... mod_perl.so' from the global
> + # httpd.conf, when using the locally built .so in the tests
> + if (eval { require mod_perl } && $mod_perl::VERSION >= 1.99 &&
> + eval {require Apache::Build} &&
> Apache::Build::IS_MOD_PERL_BUILD()) {
> + Apache::TestConfig::config_parse_skip_module_add('mod_perl.c');
> + }
> }
>
> sub configure_modperl {
>
>
> since this long conditional is already used elsewhere in Apache::Test
> should probably refactor it as an Apache::TestConfig::IS_MOD_PERL2_BUILD
> constant.
I'm still not happy about it. It needs more work to handle correctly mod_perl
1.0. Meanwhile please check the attached patch (against the current cvs).
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: finding mod_perl shared object on win32
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Mon, 31 Mar 2003, Stas Bekman wrote:
>
>
>>Randy Kobes wrote:
>>
>>>On Fri, 28 Mar 2003, Stas Bekman wrote:
>>
>
>>>>Randy,
>>>>
>>>>I've looked at this issue and I don't see this problem on
>>>>linux. Admittedly there was a problem with using -apxs which
>>>>was finding mod_perl.so when it wasn't supposed to, which
>>>>I've fixed now in cvs.
>>>>
>>>>Currently the logic goes like this (at this moment only
>>>>relevant to mod_perl 2.0 built as DSO):
>>>>
>>>>1. always ignore the whatever 'LoadModule perl_module path'
>>>>was found in global httpd.conf (that's what pre_configure()
>>>>does)
>>>>
>>>>2. look at the build config options, if such exists (which is
>>>>the case when mod_perl was installed on the system or we are
>>>>inside the core build), use the information from there
>>>>
>>>>3. otherwise die, saying oops, mod_perl is not installed
>>>
> [ ... ]
>
> Hi Stas,
> I think I've figured out why this wasn't working for
> me (having Apache-Test load the installed mod_perl.so for a 3rd
> party module) - I'm doing this for a Perl where mod_perl 2 isn't
> installed (I'm just making Apache-Test available), so the
> build config options isn't available.
> I guess this case is only a problem when using Apache 1.3.
> What about calling pre_configure() only if Apache 2.0 is being
> used, as in the following:
> ==========================================================
> Index: TestRun.pm
> ===================================================================
> RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
> retrieving revision 1.105
> diff -u -r1.105 TestRun.pm
> --- TestRun.pm 27 Mar 2003 22:19:30 -0000 1.105
> +++ TestRun.pm 19 Apr 2003 16:48:20 -0000
> @@ -560,13 +560,14 @@
>
> $self->getopts(\@argv);
>
> - $self->pre_configure() if $self->can('pre_configure');
> -
> $self->{test_config} = $self->new_test_config;
>
> - $self->warn_core();
> -
> $self->{server} = $self->{test_config}->server;
> +
> + $self->pre_configure()
> + if ($self->can('pre_configure') && $self->{server}->{version} !~ /1.3/);
> +
> + $self->warn_core();
>
> local($SIG{__DIE__}, $SIG{INT});
> $self->install_sighandlers;
> =======================================================================
> I think this should only affect building 3rd party modules
> with Apache 1.3, as things should have died long before this
> if trying to build mod_perl 2 with Apache 1.3.
Understood. How about this patch:
Index: Apache-Test/lib/Apache/TestRunPerl.pm
===================================================================
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRunPerl.pm,v
retrieving revision 1.10
diff -u -r1.10 TestRunPerl.pm
--- Apache-Test/lib/Apache/TestRunPerl.pm 26 Jan 2003 03:14:04 -0000
1.10
+++ Apache-Test/lib/Apache/TestRunPerl.pm 21 Apr 2003 03:53:53 -0000
@@ -14,8 +14,12 @@
sub pre_configure {
my $self = shift;
- Apache::TestConfig::config_parse_skip_module_add('mod_perl.c');
-
+ # don't pick up 'LoadModule ... mod_perl.so' from the global
+ # httpd.conf, when using the locally built .so in the tests
+ if (eval { require mod_perl } && $mod_perl::VERSION >= 1.99 &&
+ eval {require Apache::Build} && Apache::Build::IS_MOD_PERL_BUILD()) {
+ Apache::TestConfig::config_parse_skip_module_add('mod_perl.c');
+ }
}
sub configure_modperl {
since this long conditional is already used elsewhere in Apache::Test should
probably refactor it as an Apache::TestConfig::IS_MOD_PERL2_BUILD constant.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org