You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Geoffrey Young <ge...@modperlcookbook.org> on 2003/03/13 15:52:07 UTC
fresh install can't find Apache2.pm
hey...
I recently lost a drive on my sandbox and had to install perl, apache,
and mod_perl all from scratch.
mod_perl 1.0 installed just fine.
mod_perl 2.0 compiles and tests ok, but I can't run make install:
make[1]: Leaving directory `/src/modperl-2.0/src/modules/perl'
Can't locate Apache2.pm in @INC (@INC contains: blib/lib/Apache2
/src/bleedperl/lib/5.9.0/i686-linux-thread-multi /src/bleedperl/lib/5.9.0
/src/bleedperl/lib/5.9.0/i686-linux-thread-multi /src/bleedperl/lib/5.9.0
/src/bleedperl/lib/site_perl/5.9.0/i686-linux-thread-multi
/src/bleedperl/lib/site_perl/5.9.0 /src/bleedperl/lib/site_perl .).
BEGIN failed--compilation aborted.
make: *** [pure_site_install] Error 2
there's really no way to tell for how long this has been an error, since
Apache2.pm would have been in my @INC from previous successful installs.
anyway, if somebody could go through the pain of verifying this, that would
be great - I'm not sure if the problem is with the Makefile/ModPerl::MM or
the placement of Apache2.pm (./blib/lib/Apache2.pm).
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: fresh install can't find Apache2.pm
Posted by Stas Bekman <st...@stason.org>.
Nick Tonkin wrote:
> On Thu, 13 Mar 2003, Geoffrey Young wrote:
>
>
>>hey...
>>
>> I recently lost a drive on my sandbox and had to install perl, apache,
>>and mod_perl all from scratch.
>>
>>mod_perl 1.0 installed just fine.
>>
>>mod_perl 2.0 compiles and tests ok, but I can't run make install:
>>
>>make[1]: Leaving directory `/src/modperl-2.0/src/modules/perl'
>>Can't locate Apache2.pm in @INC (@INC contains: blib/lib/Apache2
>>/src/bleedperl/lib/5.9.0/i686-linux-thread-multi /src/bleedperl/lib/5.9.0
>>/src/bleedperl/lib/5.9.0/i686-linux-thread-multi /src/bleedperl/lib/5.9.0
>>/src/bleedperl/lib/site_perl/5.9.0/i686-linux-thread-multi
>>/src/bleedperl/lib/site_perl/5.9.0 /src/bleedperl/lib/site_perl .).
>>BEGIN failed--compilation aborted.
>>make: *** [pure_site_install] Error 2
>>
>>there's really no way to tell for how long this has been an error, since
>>Apache2.pm would have been in my @INC from previous successful installs.
>>
>>anyway, if somebody could go through the pain of verifying this, that would
>>be great - I'm not sure if the problem is with the Makefile/ModPerl::MM or
>>the placement of Apache2.pm (./blib/lib/Apache2.pm).
>
>
> FWIW my recent fresh install of perl 5.8.0 and apache2/mp2 did not
> encounter this problem.
You'd if you first do:
grep /whereever/your/perl5/lib/is/ -name "Apache2" -exec rm -r {} \;
or simply:
grep /whereever/your/perl5/lib/is/ -name "Apache2.pm" -exec rm {} \;
The patch is on the way.
__________________________________________________________________
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: fresh install can't find Apache2.pm
Posted by Nick Tonkin <ni...@tonkinresolutions.com>.
On Thu, 13 Mar 2003, Geoffrey Young wrote:
> hey...
>
> I recently lost a drive on my sandbox and had to install perl, apache,
> and mod_perl all from scratch.
>
> mod_perl 1.0 installed just fine.
>
> mod_perl 2.0 compiles and tests ok, but I can't run make install:
>
> make[1]: Leaving directory `/src/modperl-2.0/src/modules/perl'
> Can't locate Apache2.pm in @INC (@INC contains: blib/lib/Apache2
> /src/bleedperl/lib/5.9.0/i686-linux-thread-multi /src/bleedperl/lib/5.9.0
> /src/bleedperl/lib/5.9.0/i686-linux-thread-multi /src/bleedperl/lib/5.9.0
> /src/bleedperl/lib/site_perl/5.9.0/i686-linux-thread-multi
> /src/bleedperl/lib/site_perl/5.9.0 /src/bleedperl/lib/site_perl .).
> BEGIN failed--compilation aborted.
> make: *** [pure_site_install] Error 2
>
> there's really no way to tell for how long this has been an error, since
> Apache2.pm would have been in my @INC from previous successful installs.
>
> anyway, if somebody could go through the pain of verifying this, that would
> be great - I'm not sure if the problem is with the Makefile/ModPerl::MM or
> the placement of Apache2.pm (./blib/lib/Apache2.pm).
FWIW my recent fresh install of perl 5.8.0 and apache2/mp2 did not
encounter this problem.
- nick
--
~~~~~~~~~~~~~~~~~~~~
Nick Tonkin {|8^)>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: fresh install can't find Apache2.pm
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>>> 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.
>>
>>
>>
>> Well, nobody has followed up on my proposal and related problems, so
>> may be you should first take a look at it.
>> http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=104411330329305&w=2
>> If I didn't have the questions, I'd have committed it long time ago.
>> Your advice is that I'm after.
>
>
> since you asked :)
>
> ok, I think what I'd really like to see for third party modules is
> something as simple as
>
> use ModPerl::MM::Dist qw(WriteMakefile);
>
> WriteMakefile (
> # standard MakeMaker stuff
> 'NAME' => 'Apache::Clean',
> 'VERSION_FROM' => 'Clean.pm',
> 'PREREQ_PM' => { HTML::Clean => 0.8,
> mod_perl => 1.99 },
That's exactly what I was trying to achieve.
Please explain the next two lines:
> # override mod_perl specific defaults
> 'Apache::Test' => 0, # Apache::Test harness is built by default
You mean the import of 'test' and 'clean' targets?
> 'AUTO_APACHE2' => 0, # installs to Apache/ or Apache2 by default
You don't need to control this one. If mod_perl 2.0 was installed into
Apache2/, it should figure that out by itself and install the 3rd party module
into the same location.
Why would you want to have a control over it?
> )
>
> what I'm really talking about is adding a single line to a standard
> Makefile.PL (the use() one) and everything is good to go automagically.
> this will ease the burden considerably on module writers.
That will work for simple pure-perl things mostly. Once you want to mess with
generated Makefile, you want to have a full control over it, while having MM
help you with the mod_perl specific bits.
> the overridden_method stuff really doesn't appeal to me, and I can't say
> that I see why it needs to be that way if we were to design things
> better (though it may mean more work for us).
That was an attempt to make things sub-classable.
> can't we just import what we want into the MY:: namespace? my latest
> Makefile.PL
>
> http://search.cpan.org/src/GEOFF/Apache-Clean-2.02b/Makefile.PL
>
> does everything I want it to - the only thing I can immediately see
> that's missing are XS hooks.
that *only thing* is not so simple. Try to port an XS module and you will see
that you end up with writing woodoo code to generate the right makefile
targets and they will most likely break if mod_perl changes things just a bit.
> but at any rate, the
>
> *MY::constants = \&ModPerl::MM::MY::constants;
>
> was both essential and worked just fine. can't we do something similar
> behind the scenes in a subclass so that it's all transparent?
Not, if you want to re-use the mod_perl target, and modify it to suit your
needs. e.g. adding some actions, removing some or the hardest modify.
> Maybe a good design is to have ModPerl::MM as the base class, then make
> ::Build for the mod_perl proper build stuff and ::Dist for third party
> modules (or ::CPAN or something).
That's the idea. It would work perfectly if the EU::MM was designed this way.
But it doesn't.
If you give it a try you will see that the way EU::MM override works, makes it
almost impossible to sub-class things (more than one level), which I was
trying to work around with overridden_methods.
__________________________________________________________________
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: fresh install can't find Apache2.pm
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> 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.
>
>
> Well, nobody has followed up on my proposal and related problems, so may
> be you should first take a look at it.
> http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=104411330329305&w=2
> If I didn't have the questions, I'd have committed it long time ago.
> Your advice is that I'm after.
since you asked :)
ok, I think what I'd really like to see for third party modules is something
as simple as
use ModPerl::MM::Dist qw(WriteMakefile);
WriteMakefile (
# standard MakeMaker stuff
'NAME' => 'Apache::Clean',
'VERSION_FROM' => 'Clean.pm',
'PREREQ_PM' => { HTML::Clean => 0.8,
mod_perl => 1.99 },
# override mod_perl specific defaults
'Apache::Test' => 0, # Apache::Test harness is built by default
'AUTO_APACHE2' => 0, # installs to Apache/ or Apache2 by default
)
what I'm really talking about is adding a single line to a standard
Makefile.PL (the use() one) and everything is good to go automagically.
this will ease the burden considerably on module writers.
the overridden_method stuff really doesn't appeal to me, and I can't say
that I see why it needs to be that way if we were to design things better
(though it may mean more work for us).
can't we just import what we want into the MY:: namespace? my latest
Makefile.PL
http://search.cpan.org/src/GEOFF/Apache-Clean-2.02b/Makefile.PL
does everything I want it to - the only thing I can immediately see that's
missing are XS hooks. but at any rate, the
*MY::constants = \&ModPerl::MM::MY::constants;
was both essential and worked just fine. can't we do something similar
behind the scenes in a subclass so that it's all transparent?
Maybe a good design is to have ModPerl::MM as the base class, then make
::Build for the mod_perl proper build stuff and ::Dist for third party
modules (or ::CPAN or something).
anyway, those are my initial thoughts.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: fresh install can't find Apache2.pm
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>>
>> I've also seen this at the install level, on a fresh install
>> (otherwise, as you say, it picks things up in the system perl
>> tree). I guess it's because @INC should also include blib/lib?
>> I've just set PERL5LIB to get around this, for now.
>>
>
> 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.
Thanks Geoff. I've committed a temp workaround till a more ground solution is
provided.
> 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.
Well, nobody has followed up on my proposal and related problems, so may be
you should first take a look at it.
http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=104411330329305&w=2
If I didn't have the questions, I'd have committed it long time ago. Your
advice is that I'm after.
__________________________________________________________________
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: fresh install can't find Apache2.pm
Posted by Stas Bekman <st...@stason.org>.
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.
True. I haven't noticed that, because I haven't added a live-mod_perl test
suite for my guinea pig, Apache::Peek ;) I'll certainly fix that.
> 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.
>
> At one point Stas mentioned the problem that users may not have
> mod_perl 2 installed, or may not have the latest version, and so
> authors making up a 3rd party distribution can't depend on
> functions available there. Would CPAN::MakeMaker be helpful in
> this regard? Basically one can put stuff in a CPAN/MakeMaker.pm
> file that gets distributed with the distribution, but not
> installed.
As I understand CPAN::MakeMaker is needed for backporting. We haven't released
anything yet, so we don't really need to use it.
Next week I'll probably start pounding on the MM issue again. Meanwhile your
comments on my original subclassing MM are very needed. 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 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
finding mod_perl shared object on win32
Posted by Stas Bekman <st...@stason.org>.
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: fresh install can't find Apache2.pm
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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.
At one point Stas mentioned the problem that users may not have
mod_perl 2 installed, or may not have the latest version, and so
authors making up a 3rd party distribution can't depend on
functions available there. Would CPAN::MakeMaker be helpful in
this regard? Basically one can put stuff in a CPAN/MakeMaker.pm
file that gets distributed with the distribution, but not
installed.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: fresh install can't find Apache2.pm
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>
> I've also seen this at the install level, on a fresh install
> (otherwise, as you say, it picks things up in the system perl
> tree). I guess it's because @INC should also include blib/lib?
> I've just set PERL5LIB to get around this, for now.
>
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.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: fresh install can't find Apache2.pm
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Thu, 13 Mar 2003, Geoffrey Young wrote:
> hey...
>
> I recently lost a drive on my sandbox and had to install perl, apache,
> and mod_perl all from scratch.
>
> mod_perl 1.0 installed just fine.
>
> mod_perl 2.0 compiles and tests ok, but I can't run make install:
>
> make[1]: Leaving directory `/src/modperl-2.0/src/modules/perl'
> Can't locate Apache2.pm in @INC (@INC contains: blib/lib/Apache2
> /src/bleedperl/lib/5.9.0/i686-linux-thread-multi /src/bleedperl/lib/5.9.0
> /src/bleedperl/lib/5.9.0/i686-linux-thread-multi /src/bleedperl/lib/5.9.0
> /src/bleedperl/lib/site_perl/5.9.0/i686-linux-thread-multi
> /src/bleedperl/lib/site_perl/5.9.0 /src/bleedperl/lib/site_perl .).
> BEGIN failed--compilation aborted.
> make: *** [pure_site_install] Error 2
I've also seen this at the install level, on a fresh install
(otherwise, as you say, it picks things up in the system perl
tree). I guess it's because @INC should also include blib/lib?
I've just set PERL5LIB to get around this, for now.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org