You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2003/03/28 05:58:16 UTC
finding mod_perl shared object on win32
Randy Kobes wrote:
> On Thu, 13 Mar 2003, Geoffrey Young wrote:
>
>
>>yeah, I think it's related to the latest change in ModPerl::MM
>>
>>http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=104432362926275&w=2
>>
>>removing -MApache2 from the macro solves the problem, but thus makes it
>>unusable for third party modules.
>>
>>I guess we really need to think harder about third party module
>>support. I know I've struggled with this lately as has Stas,
>>although ModPerl::MM::WriteMakefile seems to sorta work.
>>
>>maybe we should just revisit third party modules alltogether
>>and come up with a feature list and API, then implement from
>>scratch - possibly as a ModPerl::MM subclass or something.
>
>
> It is a bit of a quandry ... One thing that I've also noticed is
> that things are configured so that, if mod_perl.so appears in the
> installed httpd.conf within a LoadModule directive, this isn't
> included in the generated httpd.conf. That's the desired
> behaviour when building mod_perl itself, as you'd want the
> freshly built mod_perl.so used instead, but for a third party
> module you do want to load the installed mod_perl.so. One
> work-around is to have a TEST.PL something like:
>
> ========================================================
> #!perl
> use strict;
> use warnings FATAL => 'all';
> use Apache::TestRunPerl();
>
> package MyTest;
> our @ISA = qw(Apache::TestRunPerl);
> sub pre_configure {
> }
> MyTest->new->run(@ARGV);
> ========================================================
> but perhaps a more transparent way could be devised.
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
Currently I have two perl trees (I have many more but for the purpose of this
explanation let's say I have just two): ~/perl/blead and
~/perl/blead-ithreads. I've installed mod_perl using ~/perl/blead-ithreads,
but not ~/perl/blead.
Now if I build a 3rd party module with blead-ithreads, it automatically finds
mod_perl.so, because it's in BuildOptions. No matter if I provide -httpd,
-apxs or nothing at all.
If I build with blead (no mod_perl installed) it finds no mod_perl.so, no
matter if I provide -httpd, -apxs or nothing at all.
Now, Randy, can you please tell whether this logic is flowed?
__________________________________________________________________
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
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
Re: finding mod_perl shared object on win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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 Stas Bekman <st...@stason.org>.
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
>>
>>Currently I have two perl trees (I have many more but for the
>>purpose of this explanation let's say I have just two):
>>~/perl/blead and ~/perl/blead-ithreads. I've installed mod_perl
>>using ~/perl/blead-ithreads, but not ~/perl/blead.
>>
>>Now if I build a 3rd party module with blead-ithreads, it
>>automatically finds mod_perl.so, because it's in BuildOptions.
>>No matter if I provide -httpd, -apxs or nothing at all.
>>
>>If I build with blead (no mod_perl installed) it finds no
>>mod_perl.so, no matter if I provide -httpd, -apxs or nothing at
>>all.
>>
>>Now, Randy, can you please tell whether this logic is flowed?
>
>
> That sounds right, and looking at my (installed)
> Apache::BuildConfig, the basic info is there - MODPERL_LIB_DSO is
> mod_perl.so, and MODPERL_AP_LIBEXEXDIR is set to the right
> Apache2 modules/ directory. But for some reason it doesn't get
> picked up on Win32 for 3rd party modules - in the generated
> httpd.conf, a comment appears that mod_perl.so can't be located.
>
> It may be that this has been fixed by some recent commits;
> unfortunately, something's broken on Win32 in the current cvs
> version (I get a "free to wrong pool" error and then an access
> violation in perl58.dll when the tests start up). I'll try to
> find some time later this week to look at this some more.
I haven't change the search logic, other than doing some preps for searching
1.0 and static build versions, so I suppose it hasn't been fixed. It should be
very easy to trace why it doesn't find the shared library by adding some debug
prints in Apache::TestConfigPerl::configure_libmodperl.
Thanks.
__________________________________________________________________
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
Re: finding mod_perl shared object on win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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
>
> Currently I have two perl trees (I have many more but for the
> purpose of this explanation let's say I have just two):
> ~/perl/blead and ~/perl/blead-ithreads. I've installed mod_perl
> using ~/perl/blead-ithreads, but not ~/perl/blead.
>
> Now if I build a 3rd party module with blead-ithreads, it
> automatically finds mod_perl.so, because it's in BuildOptions.
> No matter if I provide -httpd, -apxs or nothing at all.
>
> If I build with blead (no mod_perl installed) it finds no
> mod_perl.so, no matter if I provide -httpd, -apxs or nothing at
> all.
>
> Now, Randy, can you please tell whether this logic is flowed?
That sounds right, and looking at my (installed)
Apache::BuildConfig, the basic info is there - MODPERL_LIB_DSO is
mod_perl.so, and MODPERL_AP_LIBEXEXDIR is set to the right
Apache2 modules/ directory. But for some reason it doesn't get
picked up on Win32 for 3rd party modules - in the generated
httpd.conf, a comment appears that mod_perl.so can't be located.
It may be that this has been fixed by some recent commits;
unfortunately, something's broken on Win32 in the current cvs
version (I get a "free to wrong pool" error and then an access
violation in perl58.dll when the tests start up). I'll try to
find some time later this week to look at this some more.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org