When running t/TEST -conf we have a potential problem of picking mod_perl.so
built against a different perl. I'm trying to think how to resolve that. Is
there a portable way to run 'ldd', to check the signature? e.g I can do:
/tmp> ldd /home/stas/httpd/prefork/modules/mod_perl.so | grep libperl.
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
Geoffrey Young wrote:
whoops, I snipped the other stuff by accident :)
I was thinking about having the env vars set in the startup file. So
later on you just have to set MOD_PERL=2 or MOD_PERL=1.
So I do propose to change Apache::Test to use:
APXS APACHE APACHE_GROUP APACHE_USER APACHE_PORT
when
sure, we can have a new release soonish. We need to ask Doug about it.
Though I want to have the issue with bundling and dual-life CPAN packages
settled down first, before we can release Apache::Test separately. Since it
may cause mod_perl 2.0 installation when Apache::Test is requested (however
whoops, I snipped the other stuff by accident :)
I was thinking about having the env vars set in the startup file. So
later on you just have to set MOD_PERL=2 or MOD_PERL=1.
So I do propose to change Apache::Test to use:
APXS APACHE APACHE_GROUP APACHE_USER APACHE_PORT
when it detects mod_perl 1
if you're thinking about doing this, a mod_perl 2.0 CPAN release might
also be nice
What do you mean? It's been released every time a new version was
announced. It's just invisible through indexer, because of the _09
segment. You can still get it from doug's CPAN dir.
sorry, I meant a new v
On Fri, 28 Mar 2003, Stas Bekman wrote:
> Nick Tonkin wrote:
> [...]
> >>What you are talking about is the responsibility of Bundle::Apache and
> >>Bundle::Apache2. And indeed Bundle::Apache includes Apache::Request, so
> >>whenever you get a new perl install do:
> >>
> >>perl -MCPAN -e install Bu
[changing subject as we are far from discussing unimport here]
Geoffrey Young wrote:
You know what? I think we should educate the users to use env vars.
doesn't that sorta happen now - throw an error message if it can't find
a suitable Apache? granted, it could be more explicit, maybe even
Geoffrey Young wrote:
[EMAIL PROTECTED] wrote:
stas2003/03/24 23:51:08
Modified:src/modules/perl mod_perl.c modperl_cmd.c modperl_interp.c
Log:
move the modperl_interp_init() trace inside the function itself
this change throws the following error for me
modperl_interp.c: In
Nick Tonkin wrote:
[...]
What you are talking about is the responsibility of Bundle::Apache and
Bundle::Apache2. And indeed Bundle::Apache includes Apache::Request, so
whenever you get a new perl install do:
perl -MCPAN -e install Bundle::Apache
and you get all the essential mp1 modules installed.
On Thu, 27 Mar 2003, Stas Bekman wrote:
> [moving the discussion from another list. see the p5p list for the whole
> story, this is just a snippet of the thread]
I _did_ remove p5p from my reply to you and module_authors :)
>
> Stas Bekman wrote:
>
> First of all this is a more generic probl
[EMAIL PROTECTED] wrote:
stas2003/03/24 23:51:08
Modified:src/modules/perl mod_perl.c modperl_cmd.c modperl_interp.c
Log:
move the modperl_interp_init() trace inside the function itself
this change throws the following error for me
modperl_interp.c: In function `modperl_interp
prompt? I hope that was just a slip :) I much prefer the current
method (die with an error message) over the libapreq test method (wait
indefinitely for an entry or ! to skip).
Nope, not a slip. If you install manually I agree that die is better
than prompt. If you install with CPAN, which i
13 matches
Mail list logo
