from:"steve"

Perrin,

Thanks for your response...my replies below:
--
   Steve Bannerman
   [EMAIL PROTECTED]
   44.(0)1865.273866


 -Original Message-
 From: Perrin Harkins [mailto:[EMAIL PROTECTED]
 Sent: 06 August 2003 20:40
 To: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: RE: HTTP POST: parameters empty when using
 ModPerl::Registry(okay when using ModPerl:PerlRun)...

 ...snip...

 I believe I see the source of your troubles in the code that you
 posted.  You are creating a closure by using a lexical variable and then
 accessing it from within a sub.  This is a no-no with any long-running
 system like mod_perl.  You can get away with it in a standard CGI
 environment (or PerlRun) because it just exits after each request
 instead of running the same code again.

 Here is the offending section:

 my $cgi = new CGI;
 saveFile();

 sub saveFile {
   my $inputfile = $cgi-param('file');
 ... etc ...
 }

 Change it to this:

 my $cgi = new CGI;
 saveFile($cgi);

 sub saveFile {
   my $cgi = shift;
   my $inputfile = $cgi-param('file');
 ... etc ...
 }

 I think that will do it.

You're correct...that made it work.

So with respect to your explanation about the long running perl system, am
I to understand that the old version of the saveFile() subroutine uses a
reference to a different $cgi instance that the $cgi instance in the main
body of the script?

As I said, I'm new to perl but that seems to be an awfully strange behavior
of the language...if true, shouldn't the compilation (of the subroutine)
fail because it references an undeclared variable ($cgi)?

Cheers


 - Perrin

RE: HTTP POST: parameters empty when usingModPerl::Registry(okay when using ModPerl:PerlRun)...

Perrin,

Thanks...your explanation makes sense.

I was thinking of the subroutine as a method on a class and that the objects
in the class had a cgi instance associated with them.  I was thinking in the
object paradigm rather than in the procedural paradigm.

Cheers
--
   Steve Bannerman
   [EMAIL PROTECTED]
   44.(0)1865.273866


 -Original Message-
 From: Perrin Harkins [mailto:[EMAIL PROTECTED]
 Sent: 07 August 2003 19:10
 To: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: RE: HTTP POST: parameters empty when
 usingModPerl::Registry(okay when using ModPerl:PerlRun)...


 On Thu, 2003-08-07 at 03:36, Steve Bannerman wrote:
  So with respect to your explanation about the long running
 perl system, am
  I to understand that the old version of the saveFile() subroutine uses a
  reference to a different $cgi instance that the $cgi instance
 in the main
  body of the script?

 It uses a reference to the $cgi variable that was in scope when
 saveFile() was compiled.

  As I said, I'm new to perl but that seems to be an awfully
 strange behavior
  of the language...if true, shouldn't the compilation (of the subroutine)
  fail because it references an undeclared variable ($cgi)?

 But it doesn't reference an undeclared variable; it references the
 original $cgi that was available when the sub was compiled.

 Closures are a feature of Perl.  You can read about them in general in
 perlfaq7 and the perlref man page:
 http://www.perldoc.com/perl5.8.0/pod/perlfaq7.html#What's-a-closure-
 http://www.perldoc.com/perl5.8.0/pod/perlref.html

 Note that those both talk a lot about anonymous subs, but any sub can be
 a closure if it refers to a lexical variable defined in an enclosing
 scope.

 There is some mod_perl specific stuff on this here:
 http://perl.apache.org/docs/general/perl_reference/perl_reference.
html#my___Scoped_Variable_in_Nested_Subroutines

If you had warnings on, you would have received a message about $cgi not
staying shared.

In brief terms, what happens is that your program creates a lexical
called $cgi, then saveFile() refers to it, locking in that variable as
the $cgi that will always be referenced by saveFile().  At the end of
the script $cgi goes out of scope and disappears, but saveFile() keeps
referencing it.

In a CGI program this is not a problem, because Perl exits and the
process quits.  In mod_perl, the code gets run again and saveFile()
still refers to the original $cgi.

There are a number of ways to solve this problem, but I prefer the one I
showed you.  Explicitly passing all arguments to subs is well
established as a best practice in programming.  What you were doing with
$cgi before is basically treating it as a global.  So, I'd suggest you
turn on warnings, turn on strict, and embrace the good practice of
passing variables to your subs.

- Perrin

Re: [mp2] Child process exited

Jean-Sebastien Guay wrote:

Steve,

 

and the good news for you is that I've reproduced your problem.
   

GREAT! Thank you so much for persevering through this! So do you have a
traceback or some info that the developers might be able to use to track
this down?
Not sure how to get a stack backtrace on Windows.  I don't even get the 
Application Error popup window with a Debug button inviting me to have 
go :-(

However, I have massively simplified the test program that reproduces 
the problem.

I've moved the template itself in-core rather than processing an 
external file and removed everything else that I could without the 
problem going away.  I found that almost whatever I removed from the 
template -- not just the nobr tag -- fixed it, and I began to wonder 
about the *size* of the template.

So then I replaced the HTML page content with loads of dots, and sure 
enough, the problem goes away if you reduce the number of dots 
sufficiently.  It seems that the program breaks if the template size is 
 612 bytes, and works if it is = 612 bytes!  (Try changing $size from 
613 to 612 in getTemplate() to fix it!)

Template-Toolkit's Template::Manual::Config manpage says that Perl will 
segfault using the INTERPOLATE option with templates  32 kB due to 
limitations in Perl's regex engine, and sure enough another way to fix 
the attached program is to change INTERPOLATE = 1 to INTERPOLATE = 0.

I don't know where the 612 byte limit comes from, but it's certainly not 
Perl itself that has such a small limit -- the program runs fine in CGI 
and mod_perl 1 environments with $size set way higher than 32 kB on my 
machine.

So a temporary fix would appear to be to not use the INTERPOLATE option 
if you can manage without it.

I might have to leave it to Randy for a fuller explanation of where the 
612 bytes limit is creeping in.

Steve
#!perl

use strict;
use warnings;

use Template;

MAIN: {
print qq[Content-Type: text/html\n\n];
processTemplate();
}

sub processTemplate {
my $template = Template-new({ INTERPOLATE = 1 });
my $t_text = getTemplate();
$template-process($t_text)
or die(Error processing template:  . $template-error());
}

sub getTemplate {
my $size = 612;

my $header = 'htmlbody';
my $footer = '/body/html';
my $centre = '.' x ($size - length($header) - length($footer));
my $t_text = $header . $centre . $footer;

return \$t_text;
}

RE: HTTP POST: parameters empty when using ModPerl::Registry (okay when using ModPerl:PerlRun)...

Stas,

Replies below:
--
   Steve Bannerman
   [EMAIL PROTECTED]
   44.(0)1865.273866


 -Original Message-
 From: Stas Bekman [mailto:[EMAIL PROTECTED]
 Sent: 05 August 2003 18:07
 To: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: Re: HTTP POST: parameters empty when using ModPerl::Registry
 (okay when using ModPerl:PerlRun)...


  ...snip...
 

 The docs need work, this is just a copy of mp1 registry docs, which need
 adjustments. However most things work the same way. The
 differences between
 Registry and PerlRun are easily summarizes with this diff:

 ModPerl-Registry diff -u lib/ModPerl/Registry.pm lib/ModPerl/PerlRun.pm
 --- lib/ModPerl/Registry.pm 2003-03-22 20:52:24.0 -0800
 +++ lib/ModPerl/PerlRun.pm  2003-03-22 20:52:24.0 -0800
 @@ -1,4 +1,4 @@
 -package ModPerl::Registry;
 +package ModPerl::PerlRun;

   use strict;
   use warnings FATAL = 'all';
 @@ -30,11 +30,11 @@
   make_namespace  = 'make_namespace',
   namespace_root  = 'namespace_root',
   namespace_from  = 'namespace_from_filename',
 -is_cached   = 'is_cached',
 -should_compile  = 'should_compile_if_modified',
 -flush_namespace = 'NOP',
 +is_cached   = 'FALSE',
 +should_compile  = 'TRUE',
 +flush_namespace = 'flush_namespace_normal',
   cache_table = 'cache_table_common',
 -cache_it= 'cache_it',
 +cache_it= 'NOP',
   read_script = 'read_script',
   rewrite_shebang = 'rewrite_shebang',
   set_script_name = 'set_script_name',
 @@ -53,17 +53,10 @@

 PerlRun doesn't cache the script on each request and it flushes
 the script's
 namespace on each request. You can see the actual functions in
 lib/ModPerl/RegistryCooker.pm.

Thanks, that's helpful...it shows me why PerlRun works.

However, it doesn't really explain why the root problem exists.  The way I
think about it, the creation of a new CGI object should create a new set
of slots for instance data.  Then, each request's parameters would be
stored in a slot of the new CGI instance rather than in the global set of
slots for the class of CGI instances.

Maybe I don't understand the object paradigm in perl correctly; however, I
do understand it very well in general.  Thus, it seems like a defect in
either perl (the language) or CGI.pm.  I'm guessing there's some
justification for it in performance...however, it just doesn't seem right.

Thoughts?

 If you can try to take it from
 here and see
 what the problem is (your code/registry?), that would be cool. Thanks.


Unfortunately, I don't really know how to take it from here.  I'm pretty
new to perl and very new to mod_perl.  Thus I'm reaching out to you guys
to find out if anybody has solved this problem...unfortunately,
Christopher's suggestion didn't work (unless I implemented it incorrectly).

 Also make sure you are using the latest CGI.pm (2.93 or higher is good).

I'm using CGI.pm-2.98.

Cheers


 __
 Stas BekmanJAm_pH -- Just Another mod_perl Hacker
 http://stason.org/ mod_perl Guide --- http://perl.apache.org
 mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
 http://modperlbook.org http://apache.org   http://ticketmaster.com

Re: [mp2] Child process exited

Jean-Sebastien Guay wrote:

Steve,

 

How did you build Apache 2?
   

I downloaded the binaries... Sorry, can't help there.

Please keep me posted as to your progress.
 

OK, I've now got Apache 2 building (with a little off-list help from 
Randy Kobes - the secret is to use the .zip sources rather than the 
.tar.gz sources!), and I've built mod_perl 1.99_09 (not 1.99_10-dev as 
your have) and the good news for you is that I've reproduced your problem.

The bads news is that I haven't solved it, but I'll keep trying and let 
you know if/when I do.

I don't any Application Error popup window, but my NS7.1 browser says 
The document contained no data, while IE6.0 gives the usual useless 
The page cannot be displayed crap that it always does.

I also get nothing in the access.log.

The error.log contained this:

Variable $template will not stay shared at 
C:/apache2/perl-bin/index.cgi line 26.
Variable $vars will not stay shared at C:/apache2/perl-bin/index.cgi 
line 26.
[Thu Aug 14 10:37:04 2003] [notice] Parent: child process exited with 
status 128 -- Restarting.

The variable will not stay shared error is a common problem with 
mod_perl scripts that have file-scope lexical variables in them which 
subroutines access.  My usual solution is to put the main part of the 
program into a block labelled MAIN:.  That way they can't be shared 
to start with, and I have to explicitly pass them into any subroutines 
that require them.  The attached new version of your index.cgi does 
this, and makes these errors go away.  I now have just this in the 
error.log:

[Thu Aug 14 10:41:42 2003] [notice] Parent: child process exited with 
status 128 -- Restarting.

The index.cgi program runs fine in a command prompt (with SCRIPT_ROOT 
set in the environment), so its not an obvious TT error.

TTYL,

Steve
#!D:\perl\bin\perl -w
#---
use strict;
use warnings;

use Template;

MAIN: {
#---
my $vars = {
VERSION = 0.75,
};

# Template toolkit config.
my $config = {
INCLUDE_PATH = $ENV{SCRIPT_ROOT},
INTERPOLATE  = 1,  # expand $var in plain text
POST_CHOMP   = 1,  # cleanup whitespace
};

my $template = Template-new($config);
#---

print qq[Content-Type: text/html\n\n];

processTemplate($template, 'header.html.tmpl', $vars);

#print qq[htmlheadtitleApache should hopefully 
crash.../title/headbody];

print plural('bottle', $_) .  of beer on the wall, br .
  plural('bottle', $_) .  of beer, br .
  Take one down and pass it around, br .
  plural('bottle', $_ - 1) .  of beer on the wall.brbr\n
foreach (reverse (1 .. 99));

print qq[/body/html];
}

#---
sub processTemplate {
my $template = shift;
my $t_file = shift;
my $vars = shift;
$template-process($t_file, $vars)
or die(Error pressing $t_file:  . $template-error);
}

sub plural {
my ($word, $number) = @_;
return ($number == 0 ? 'no' : $number) .
$word .
   ($number == 1 ? '' : 's');
}

Re: [MP1.28 + perl maint. 20512] Build failure due to error in Apache/ExtUtils.pm

Sreeji K Das wrote:

I tried to compile mod_perl-1.28 with perl maint.
20512 (http://www.iki.fi/jhi/[EMAIL PROTECTED]). I had a
build failure (different errors each time trying to
build).
Have you tried http://www.iki.fi/jhi/[EMAIL PROTECTED] ? That snapshot 
worked OK for me on WinXP.

- Steve

HTTP POST: parameters empty when using ModPerl::Registry (okay when using ModPerl:PerlRun)...

All,

I apologize if this has already been covered...I looked at the archives
since May but couldn't see anything covering this (there were related items
but their solutions didn't solve this problem).

Here an explanation of the problem:

We want to post experiment results to an upload server which is running
Apache HTTP Server (2.0.46) and mod_perl (1.99_09).  When we post a sequence
of files to the server, some of them are written to the local disk and some
are not.  That is, the test fails when using ModPerl::Registry but it
succeeds when using ModPerl::PerlRun.

In analyzing which ones work and which ones do not, I wrote a quick test to
see why the transfer is not working.  From the looks of the results, it
appears that the first request handled by a particular Apache process/thread
works and that any subsequent requests handled by that thread fail.
Works means that the file in the test gets saved to disk and fail means that
a file of size 0 gets written to disk.

Below are the httpd.conf segments (working and failing), the test client
(test_client.pl) and the test server (test_server.pl which is accessible
from the /cpdn/cgi-bin location).

Any suggestions?  Thanks in advance...

Also, does it matter if I use ModPerl::PerlRun instead of ModPerl::Registry
(I have read some about this at
http://apache.perl.org/docs/2.0/api/ModPerl/Registry.html but the
documentation there is a little light).

--
Working httpd.conf
--
Location /cpdn/cgi-bin
  AllowOverride None
  SetHandler perl-script
  PerlResponseHandler ModPerl::PerlRun
  PerlOptions +ParseHeaders
  Options +ExecCGI
  Allow from All
/Location

--
Failing httpd.conf
--
Location /cpdn/cgi-bin
  AllowOverride None
  SetHandler perl-script
  PerlResponseHandler ModPerl::Registry
  PerlOptions +ParseHeaders
  Options +ExecCGI
  Allow from All
/Location

--
test_client.pl
--
#!/usr/bin/perl
use strict;

use LWP::UserAgent;
use HTTP::Request::Common;

my $postUrl = $ARGV[0];
my $file = $ARGV[1];

my $postType = 'form-data';

my $ua = new LWP::UserAgent;
my $req = POST($postUrl,
   Content_Type = $postType,
   Content = [ file = [$file] ]);

my $res = $ua-request($req);
if ($res-is_success()) {
  print POST test successful\n;
  print $res-content();
} else {
  print STDERR POST test failed;
  print STDERR code:  . $res-code() . \n;
  print STDERR message:  . $res-message() . \n;
}

--
test_server.pl
--
use strict;
use CGI qw(:standard);

my $cgi = new CGI;
saveFile();

sub saveFile {
  my $inputfile = $cgi-param('file');
  my $outputfile = /tmp/file- . $$ . - . time();
  open(FILE,$outputfile) || printError();
  my $buffer;
  while (read($inputfile,$buffer,2096)) {
print FILE $buffer;
  }
  close(FILE);
  undef $buffer;
}

sub printError {
  print header();
  print Content-type: text/plain\n;
  print Status: 500$\n;
  print Message: Internal Error\n;
  exit;
}

Cheers
--
   Steve Bannerman
   [EMAIL PROTECTED]
   44.(0)1865.273866

Re: [mp2] Child process exited

Jean-Sebastien Guay wrote:

So, did anyone have time to check this out? This is pretty major for me,
I can't implement mod_perl at my site until I find out what is causing
this crash and fix it. And I really have no idea what could be causing
it.
I'm using CGI.pm 2.98, Template-Toolkit 2.10, Apache/2.0.47 (Win32)
mod_perl/1.99_10-dev Perl/v5.8.0.
I'm willing to try this out using Apache 2 -- I've been meaning to take 
a look at Apache 2 for some now, but just never quite got around to it 
:-( -- but at the moment I can't even build it!

I've download httpd-2.0.47.tar.gz, unpacked it, cd'd to the top-level 
directory and typed nmake /f makefile.win installr, which I believe 
should build and install (into the default location, C:\apache2) a 
release build of Apache 2.

However, that command produces this output:

==
C:\Temp\httpd-2.0.47nmake /f makefile.win installr
Microsoft (R) Program Maintenance Utility   Version 6.00.8168.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
Please check out or download and unpack the Apache Portability Runtime
sources (apr, apr-iconv and apr-util) into your \srclib dir.
Apache cannot build without these libraries!
makefile.win(39) : fatal error U1050: Need \srclib\  apr, apr-iconv and 
apr-util

Stop.
==
If I look inside the srclib directory then I only find apr, 
apr-util and pcre, not apr-iconv.  Where is that supposed to come 
from?

How did you build Apache 2?

Steve

Re: [mp2] Child process exited

Jean-Sebastien Guay wrote:

Can't get http://whitestar02.webhop.org/Files/ApacheCrash.zip

it resolves to an internal address: 192.168.0.3
   

Darn, looks like my web server didn't come back up right last night.
I'll have to be there to fix it, because ssh doesn't get through either.
Here's another link, on my ISP's server:
http://pages.infinit.net/jeans13/ApacheCrash.zip
 

Is it only mp2 that it fails under?

I've tried it under mp1.28/perl5.8.0/apache1.3.27 on WinXP and it runs fine.

What version of Template-Toolkit do you have?  It's worth ensuring that 
you're running the latest version (2.10, I think) if you suspect that it 
might be involved in the problem.

- Steve

RE: HTTP POST: parameters empty when using ModPerl::Registry (okay when using ModPerl:PerlRun)...

2003-08-06 Thread Steve Bannerman

Christopher,

Thanks for the suggestion; unfortunately, it doesn't work.  I made the
change you suggested (inserting CGI-initialize_globals(); just before
creating an instance of CGI) and restarted apache/httpd.  The same
result...the first time the script executes it saves the file
properly...after that, a file is created with 0 size.

Besides, as you (and others prescribing the use of initialize_globals())
described it, shouldn't subsequent executions of the script write the same
file as the first execution.  That is, if the parameters of the CGI
instances are actually global, wouldn't the same array of bytes still be in
the global 'file' parameter?

Cheers
--
   Steve Bannerman
   [EMAIL PROTECTED]
   44.(0)1865.273866


 -Original Message-
 From: Christopher Knight [mailto:[EMAIL PROTECTED]
 Sent: 05 August 2003 18:20
 To: Stas Bekman; [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: RE: HTTP POST: parameters empty when using ModPerl::Registry
 (okay when using ModPerl:PerlRun)...


 try
 CGI-initialize_globals();
 at the begining of the script but before you use params

 if you are depending on the 'use CGI' statement to initialize
 your params (like a command line script), it will cause
 problems in Registry.  Thats becuase it is initialized once on
 the initial 'use CGI' and it stays in memory for the life
 of the webserver.  So each time you use a script, you have to
 initialize the CGI params to your current request.

 -Original Message-
 From: Stas Bekman [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, August 05, 2003 12:07 PM
 To: [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]
 Subject: Re: HTTP POST: parameters empty when using ModPerl::Registry
 (okay when using ModPerl:PerlRun)...


 Steve Bannerman wrote:
  All,
 
  I apologize if this has already been covered...I looked at the archives
  since May but couldn't see anything covering this (there were
 related items
  but their solutions didn't solve this problem).
 
  Here an explanation of the problem:
 
  We want to post experiment results to an upload server which
 is running
  Apache HTTP Server (2.0.46) and mod_perl (1.99_09).  When we
 post a sequence
  of files to the server, some of them are written to the local
 disk and some
  are not.  That is, the test fails when using ModPerl::Registry but it
  succeeds when using ModPerl::PerlRun.
 
  In analyzing which ones work and which ones do not, I wrote a
 quick test to
  see why the transfer is not working.  From the looks of the results, it
  appears that the first request handled by a particular Apache
 process/thread
  works and that any subsequent requests handled by that thread fail.
  Works means that the file in the test gets saved to disk and
 fail means that
  a file of size 0 gets written to disk.
 
  Below are the httpd.conf segments (working and failing), the test client
  (test_client.pl) and the test server (test_server.pl which is accessible
  from the /cpdn/cgi-bin location).
 
  Any suggestions?  Thanks in advance...
 
  Also, does it matter if I use ModPerl::PerlRun instead of
 ModPerl::Registry
  (I have read some about this at
  http://apache.perl.org/docs/2.0/api/ModPerl/Registry.html but the
  documentation there is a little light).

 The docs need work, this is just a copy of mp1 registry docs, which need
 adjustments. However most things work the same way. The
 differences between
 Registry and PerlRun are easily summarizes with this diff:

 ModPerl-Registry diff -u lib/ModPerl/Registry.pm lib/ModPerl/PerlRun.pm
 --- lib/ModPerl/Registry.pm 2003-03-22 20:52:24.0 -0800
 +++ lib/ModPerl/PerlRun.pm  2003-03-22 20:52:24.0 -0800
 @@ -1,4 +1,4 @@
 -package ModPerl::Registry;
 +package ModPerl::PerlRun;

   use strict;
   use warnings FATAL = 'all';
 @@ -30,11 +30,11 @@
   make_namespace  = 'make_namespace',
   namespace_root  = 'namespace_root',
   namespace_from  = 'namespace_from_filename',
 -is_cached   = 'is_cached',
 -should_compile  = 'should_compile_if_modified',
 -flush_namespace = 'NOP',
 +is_cached   = 'FALSE',
 +should_compile  = 'TRUE',
 +flush_namespace = 'flush_namespace_normal',
   cache_table = 'cache_table_common',
 -cache_it= 'cache_it',
 +cache_it= 'NOP',
   read_script = 'read_script',
   rewrite_shebang = 'rewrite_shebang',
   set_script_name = 'set_script_name',
 @@ -53,17 +53,10 @@

 PerlRun doesn't cache the script on each request and it flushes
 the script's
 namespace on each request. You can see the actual functions in
 lib/ModPerl/RegistryCooker.pm. If you can try to take it from here and see
 what the problem is (your code/registry?), that would be cool. Thanks.

 Also make sure you are using the latest CGI.pm (2.93 or higher is good).

 __
 Stas BekmanJAm_pH -- Just Another mod_perl Hacker
 http://stason.org/ mod_perl Guide --- http

Re: need your help to test mod_perl with perl-5.8.1-RC3

2003-08-04 Thread Steve Hay

Michael G Schwern wrote:

The problem is likely the MY::dynamic hack in c/Makefile.PL.  6.05 and
previous had this:
dynamic :: Makefile $(INST_DYNAMIC) $(INST_BOOT)

6.06_01 and up have this

dynamic :: $(FIRST_MAKEFILE) $(INST_DYNAMIC) $(INST_BOOT)

for some reason, MY::dynamic is trying to lop off everything after Makefile
and moving $(INST_DYNAMIC) to a different target in MY::top_targets.
(Where INST_BOOT is run from, I dunno).  But dynamic no longer matches
/Makefile/ so the hack fails and you wind up with INST_DYNAMIC built from
two places.
Coupled with the fact that its set LINKTYPE 'static' with a comment
problems with things finding libareq.so, sort out later leads me to
believe this was a work around a MakeMaker bug.
Chaning s/(Makefile\s+).*/$1/g to
s{ \$\(INST_DYNAMIC\) }{}g;
s{ \$\(INST_BOOT\) }{}g;
should fix the symptoms by restoring the hack for a quick fix.
I tried changing the s/// to:

   $string =~ s{ \$\(INST_DYNAMIC\)}{}g;
   $string =~ s{ \$\(INST_BOOT\)}{}g;
(I've dropped the trailing spaces in the patterns), which produced:

dynamic :: $(FIRST_MAKEFILE)
   $(NOECHO) $(NOOP)
in the Makefile as desired, but now the build process fails with this error:

fatal error U1073: don't know how to make 'C:\perl5\lib\ExtUtils\typemap'

For a longer term solution, try removing the MY::dynamic and 
MY::top_targets overrides entirely, plus changing LINKTYPE to 'dynamic' and
see what happens.

I tried removing MY::dynamic and MY::top_targets, plus *adding* LINKTYPE 
'dynamic' to the Win32-specific section.  That seems to get me back to 
square one - the Makefile contains:

dynamic :: $(FIRST_MAKEFILE) $(INST_DYNAMIC) $(INST_BOOT)
   $(NOECHO) $(NOOP)
and the build fails as it originally did with:

libapreq.def : error LNK2001: unresolved external symbol boot_libapreq

Only the fix previously posted by Stas (adding 'SKIP' = [qw(dynamic 
dynamic_lib dynamic_bs)], to both WriteMakefile() calls) works for me so 
far, but Joe had a problem that...

Steve

Re: need your help to test mod_perl with perl-5.8.1-RC3

2003-08-04 Thread Steve Hay

Michael G Schwern wrote:

On Mon, Aug 04, 2003 at 08:46:27AM +0100, Steve Hay wrote:
 

I tried changing the s/// to:

  $string =~ s{ \$\(INST_DYNAMIC\)}{}g;
  $string =~ s{ \$\(INST_BOOT\)}{}g;
(I've dropped the trailing spaces in the patterns), which produced:

dynamic :: $(FIRST_MAKEFILE)
  $(NOECHO) $(NOOP)
in the Makefile as desired, but now the build process fails with this error:

fatal error U1073: don't know how to make 'C:\perl5\lib\ExtUtils\typemap'
   

That's odd.  Does that file exist?  If not, where is your typemap file?
 

Somehow, it has contrived to disappear!  It always used to exist there, 
which is why it didn't occur to me to check :-(  I must have lost it 
somewhere along the line when shoe-horning earlier MakeMaker's into place.

Having now restored that file, the patch above does indeed fix it for me.

Steve

Re: need your help to test mod_perl with perl-5.8.1-RC3

2003-08-04 Thread Steve Hay

Michael G Schwern wrote:

On Mon, Aug 04, 2003 at 09:35:55AM +0100, Steve Hay wrote:
 

Somehow, it has contrived to disappear!  It always used to exist there, 
which is why it didn't occur to me to check :-(  I must have lost it 
somewhere along the line when shoe-horning earlier MakeMaker's into place.
   

Possibly you deleted the ExtUtils/ directory?

Yes, I think I did delete it when installing MM 6.06_01 because its own 
Makefile was broken so I couldn't run nmake install.

I see that Perl's lib/ExtUtils directory contains a typemap and 
ExtUtils-MakeMaker's lib/ExtUtils directory doesn't.  So that would 
explain it.

Why isn't the typemap file distributed as part of ExtUtils-MakeMaker?

Re: need your help to test mod_perl with perl-5.8.1-RC3

Michael G Schwern wrote:

On Thu, Jul 31, 2003 at 03:23:36PM +0100, Steve Hay wrote:
 

This patch finally fixes it for me:
   

I'm glad you guys got it working, but there's still the problem of why
MakeMaker's behavior changed.  Since I tend not to touch the XS building
code much its likely a bug.  Try the snapshot on makemaker.org.  I just
fixed a minor issue with argument passing in recursive builds.
I just tried MM 6.13: that made no difference.

Then I tried the snapshot (taken at 01 Aug 2003 07:55 UTC): that failed 
loads of its own tests, but made no difference to the libapreq build 
process.

If I could see the Makefiles from 6.03 and 6.12 I might be able to figure out
what's different.  Also, if you could try various alpha versions between
those two, show the Makefiles and whether or not they exhibited the
behavior that would help alot in narrowing it down.
 

I've also tried MM 6.05: that works OK.

Attached are the various Makefiles (the top-level one, plus those from 
the c, Cookie and Request sub-directories), and a transcript of the 
nmake step, from a build using MM 6.05 (which worked) and another 
build using MM 6.12 (which failed).

I'll move on to trying out those alpha versions and get back to you on 
which was the first one that failed.

Steve


makefiles.tar.gz
Description: GNU Zip compressed data

Re: need your help to test mod_perl with perl-5.8.1-RC3

Steve Hay wrote:

Michael G Schwern wrote:


If I could see the Makefiles from 6.03 and 6.12 I might be able to 
figure out
what's different.  Also, if you could try various alpha versions between
those two, show the Makefiles and whether or not they exhibited the
behavior that would help alot in narrowing it down.
 

I've also tried MM 6.05: that works OK.

Attached are the various Makefiles (the top-level one, plus those from 
the c, Cookie and Request sub-directories), and a transcript of the 
nmake step, from a build using MM 6.05 (which worked) and another 
build using MM 6.12 (which failed).

I'll move on to trying out those alpha versions and get back to you on 
which was the first one that failed.
This bug evidently goes back a long way:  MM 6.06_02 fails in the same 
way as 6.13.

I tried to use MM 6.06_01, but it wouldn't build itself (don't know how 
to make 'C:\perl5\libNAME').  Instead, I knife-and-forked it into 
place, but when I tried to use it to build libapreq, I just got the same 
error again - don't know how to make 'C:\perl5\libNAME'.

So the best I can offer you at this stage is that something between 6.05 
and 6.06_02 broke it.  (Probably not what you wanted to hear, I guess, 
looking at the number of changes in 6.06_01.)

Steve

Re: need your help to test mod_perl with perl-5.8.1-RC3

Steve Hay wrote:

This bug evidently goes back a long way:  MM 6.06_02 fails in the same 
way as 6.13.

I tried to use MM 6.06_01, but it wouldn't build itself (don't know 
how to make 'C:\perl5\libNAME').  Instead, I knife-and-forked it into 
place, but when I tried to use it to build libapreq, I just got the 
same error again - don't know how to make 'C:\perl5\libNAME'. 
OK, I've got MM 6.06_01 building now (it was generating broken Makefiles 
-- needed to change DIRFILESEP from \ to ^\, and fill in the missing 
*PERLSAFE macros), and the bad news is that it doesn't build 
libapreq-1.2 either!  I still get the unresolved external symbol 
boot_libapreq error.

So it's one of the many changes between 6.05 and 6.06_01 that broke it.

Steve

Re: need your help to test mod_perl with perl-5.8.1-RC3

Michael G Schwern wrote:

On Fri, Aug 01, 2003 at 10:03:20AM +0100, Steve Hay wrote:
 

This bug evidently goes back a long way:  MM 6.06_02 fails in the same 
way as 6.13.

I tried to use MM 6.06_01, but it wouldn't build itself (don't know 
how to make 'C:\perl5\libNAME').  Instead, I knife-and-forked it into 
place, but when I tried to use it to build libapreq, I just got the 
same error again - don't know how to make 'C:\perl5\libNAME'. 
 

OK, I've got MM 6.06_01 building now (it was generating broken Makefiles 
-- needed to change DIRFILESEP from \ to ^\, and fill in the missing 
*PERLSAFE macros), and the bad news is that it doesn't build 
libapreq-1.2 either!  I still get the unresolved external symbol 
boot_libapreq error.

So it's one of the many changes between 6.05 and 6.06_01 that broke it.
   

Well, that narrows it down quite a bit.

Which version of mod_perl and Apache is this against and *exactly* what do
I have to do to exercise this bug?  I haven't built mod_perl in a long time.
 

I'm using Apache 1.3.27, mod_perl 1.28, libapreq-1.2, but I'm on Windows 
with MS VC++ 6.0, so this might not be very useful to you since you 
haven't got such a setup yourself...  Anyway, here goes; it's probably 
pretty similar on whatever OS you're on (perhaps with an extra 
./configure ... line before the Apache make?)

- Unpack Apache, mod_perl, libapreq into C:\Temp
- cd to C:\Temp\apache_1.3.27\src
- Run nmake /f makefile.win installr. That builds Apache and installs 
it into C:\apache by default.
- cd to C:\Temp\mod_perl-1.28
- Run perl Makefile.PL APACHE_SRC=C:/apache INSTALL_DLL=C:/apache/modules.
- Run nmake, nmake test, nmake install as usual.
- cd to C:\Temp\libapreq-1.2
- Run perl Makefile.PL
- Run nmake -- that fails with the unresolved external symbol 
boot_libapreq error.

That's it.

BTW, I've been looking at the Makefiles that I sent previously, and have 
found something interesting.  The Makefile in the c sub-directory from 
the 6.05 build contains this:

=
# --- MakeMaker dynamic section:
## $(INST_PM) has been moved to the all: target.
## It remains here for awhile to allow for old usage: make dynamic
#dynamic :: Makefile
dynamic :: Makefile
   @$(NOOP)
=
while the corresponding section from the 6.12 build contains this:

=
# --- MakeMaker dynamic section:
## $(INST_PM) has been moved to the all: target.
## It remains here for awhile to allow for old usage: make dynamic
dynamic :: $(FIRST_MAKEFILE) $(INST_DYNAMIC) $(INST_BOOT)
   $(NOECHO) $(NOOP)
=
If that's relevant, then the latter looks more likely to be correct, 
doesn't it?  Perhaps MM 6.06+ has correctly fixed a bug in MM 6.05, and 
the only problem here is that libapreq was previously relying on that bug?

Steve

Re: Apache-print() problem with UTF-8 data in Perl 5.8

Steve Hay wrote:

Randy Kobes wrote:

On Tue, 29 Jul 2003, Steve Hay wrote:

Is anybody going to take a serious look at the problem that I 
previously
reported with Apache-print()'s handling of UTF-8 data in Perl 5.8?

The patch that I sent
(http://marc.theaimsgroup.com/?l=apache-modperlm=105912130001046w=2)
seems to fix it for me on Windows as long as I've got perl #20203
incorporated.  Does it work on other platforms?
The #ifdef version-checks need a little work: on Windows (and other
platforms [-- which ones?] that rely on Perl's makedef.pl to get 
symbols
exported from the Perl library) you need perl-5.8.1; on other platforms
the test for perl-5.8.0 should be fine.  The brokenness of
Apache-print() under perl-5.8.0 on Windows et al would also need
documenting somewhere since it can't be fixed properly.


mod_perl 2 makes two special cases for handling systems that use
export files - Win32 and aix ($^O eq 'aix'). So these might
be the only two one has to worry about in this regard.
These were the only two that Nicholas Clark mentioned when I asked 
about the missing PerlIO_isutf8() on the perl-xs list, so that may 
well be true.  I will double-check with p5p to see if there are any more. 
Apparently there are a few more -- several listed in Perl's makedef.pl, 
plus VMS which evidently has a completely different build process.

The attached patch (against mod_perl 1.28) sorts out the version-check 
stuff, which was the only remaining issue that I had.  This leaves 
Apache-print() broken on Windows et al under Perl 5.8.0, and fixes it 
under Perl 5.8.0 on other platforms and under Perl 5.8.1+ on all platforms.

Steve
--- Apache.xs.orig  2003-06-06 12:31:10.0 +0100
+++ Apache.xs   2003-07-31 09:45:37.0 +0100
@@ -51,6 +51,16 @@
 #include mod_perl.h
 #include mod_perl_xs.h
 
+/* Figure out if we've got PerlIO_isutf8(). This is needed to handle UTF-8
+ * data correctly in Perl 5.8.0+, but was not exported by Perl in 5.8.0 itself
+ * on those OS's where symbols to export have to be explicitly listed. */
+#if !( PERL_REVISION  5 || \
+  (PERL_REVISION == 5  PERL_VERSION  8) || \
+  (PERL_REVISION == 5  PERL_VERSION == 8  PERL_SUBVERSION == 0  \
+   (defined(WIN32) || defined(NETWARE) || defined(OS2) || \
+defined(_AIX) || defined(MACOS_TRADITIONAL) || defined(VMS))) )
+#define _HAVE_ISUTF8
+#endif
 
 #ifdef USE_SFIO
 #undef send_fd_length
@@ -1119,11 +1129,27 @@
SV *sv = sv_newmortal();
SV *rp = ST(0);
SV *sendh = perl_get_sv(Apache::__SendHeader, TRUE);
+#ifdef _HAVE_ISUTF8
+   PerlIO *fp = IoOFP(GvIOp(defoutgv));
+#endif
 
if(items  2)
do_join(sv, sv_no, MARK+1, SP); /* $sv = join '', @_[1..$#_] */
 else
sv_setsv(sv, ST(1));
+#ifdef _HAVE_ISUTF8
+   if (PerlIO_isutf8(fp)) {
+   if (!SvUTF8(sv))
+   sv_utf8_upgrade(sv = sv_mortalcopy(sv));
+   }
+   else if (DO_UTF8(sv)) {
+   if (!sv_utf8_downgrade((sv = sv_mortalcopy(sv)), TRUE)
+ckWARN_d(WARN_UTF8))
+   {
+   Perl_warner(aTHX_ packWARN(WARN_UTF8), Wide character in print);
+   }
+   }
+#endif
 
PUSHMARK(sp);
XPUSHs(rp);
@@ -1176,6 +1202,20 @@
int sent = 0;
 SV *sv = SvROK(ST(i))  (SvTYPE(SvRV(ST(i))) == SVt_PV) ?
  (SV*)SvRV(ST(i)) : ST(i);
+#ifdef _HAVE_ISUTF8
+   PerlIO *fp = IoOFP(GvIOp(defoutgv));
+   if (PerlIO_isutf8(fp)) {
+   if (!SvUTF8(sv))
+   sv_utf8_upgrade(sv = sv_mortalcopy(sv));
+   }
+   else if (DO_UTF8(sv)) {
+   if (!sv_utf8_downgrade((sv = sv_mortalcopy(sv)), TRUE)
+ckWARN_d(WARN_UTF8))
+   {
+   Perl_warner(aTHX_ packWARN(WARN_UTF8), Wide character in print);
+   }
+   }
+#endif
buffer = SvPV(sv, len);
 #ifdef APACHE_SSL
 while(len  0) {

Re: need your help to test mod_perl with perl-5.8.1-RC3

Stas Bekman wrote:

Jarkko has just released perl-5.8.1-RC3. Quite a few things have 
changed since 5.8.0. So it's *very* important that you test your code 
with this release and immediatelly report to p5p if you have any 
problems, since Jarkko wants to release 5.8.1 any moment now.
BAD NEWS:  There seems to be a problem with ExtUtils-MakeMaker 6.12 
included in perl-5.8.1-RC3.

I successfully built and tested mod_perl 1.28 using RC3 on Windows XP / 
MS VC++ 6.0, but I just thought that I'd give libapreq-1.2 a quick whirl 
as well, and found that it doesn't build.  I get the following error:

...
link -out:..\blib\arch\auto\libapreq\libapreq.dll
...
libapreq.def : error LNK2001: unresolved external symbol boot_libapreq
If I downgrade ExtUtils-MakeMaker to 6.03 (the version included in 
perl-5.8.0) then it it's all OK.

The question is: why is it trying to build libapreq.dll?  It should 
only build Request.dll and Cookie.dll, which would probably explain 
why boot_libapreq is undefined.

I'll continue looking into it myself, and can supply more info to anyone 
that wants it, but I thought I'd better raise the alarm quickly first.

Steve

Re: need your help to test mod_perl with perl-5.8.1-RC3

Stas Bekman wrote:

Here is what happens:

MM 6.03 used to create libapreq.a but not libapreq.so, libapreq.a was 
just a by product and never was intented to be installed. Request.so 
was statically linking libapreq.a into it.

Now with 6.12 it creates both libapreq.so and libapreq.so, so when 
Request.so is linked, it links libapreq.so dynamically, and of course 
it can't resolve it later when loading.

This patch fixes things for me in libapreq and works with MM 6.03 and 
6.12. Steve, please confirm that it works for you and I'll commit it. 
No, it doesn't fix it :-(

My problem sounds a little different to yours.  You talk above about 
... when Request.so is linked..., but my build process doesn't get 
that far.

Under MM 6.03 it used to build libapreq.lib, then Request.dll then 
Cookie.dll.
Now, under MM 6.12, it builds libapreq.lib, then falls over 
(boot_libapreq unresolved) when trying to build libapreq.dll.

It seems likely that if my build ever got as far as trying to build 
Request.dll then it would fail without your patch, and your patch would 
fix that bit, but at the moment I'm not getting that far.

Steve

Re: need your help to test mod_perl with perl-5.8.1-RC3

Stas Bekman wrote:

Steve Hay wrote:

Stas Bekman wrote:

Stas Bekman wrote:

Steve Hay wrote:

Stas Bekman wrote:

Here is what happens:

MM 6.03 used to create libapreq.a but not libapreq.so, libapreq.a 
was just a by product and never was intented to be installed. 
Request.so was statically linking libapreq.a into it.

Now with 6.12 it creates both libapreq.so and libapreq.so, so 
when Request.so is linked, it links libapreq.so dynamically, and 
of course it can't resolve it later when loading.

This patch fixes things for me in libapreq and works with MM 6.03 
and 6.12. Steve, please confirm that it works for you and I'll 
commit it. 






No, it doesn't fix it :-(

My problem sounds a little different to yours.  You talk above 
about ... when Request.so is linked..., but my build process 
doesn't get that far.

Under MM 6.03 it used to build libapreq.lib, then Request.dll then 
Cookie.dll.
Now, under MM 6.12, it builds libapreq.lib, then falls over 
(boot_libapreq unresolved) when trying to build libapreq.dll.




I think the cause is the same. MM 6.12 builds the shared object of 
libapreq (dll in your case and .so in mine), and it didn't use to 
do that.




OK, try this patch: 


No, still doesn't fix it :-(

Doesn't seem to make any difference, actually.  It still tries to 
build libapreq.dll, and still fails in the same way.  I've attached 
the c/Makefile that was generated by the patched c/Makefile.PL (which 
should have skipped the dynamic_* bits, but seems not to have done).


But it never received the SKIP argument, from your Makefile:

 #   MakeMaker Parameters:

 # INC = q[ -IC:/apache/include 
-IC:/apache/include/../os/win32 
-IC:/Temp/mod_perl-1.28/src/modules/perl ]
 # NAME = q[libapreq]
 # OBJECT = q[apache_request.o apache_cookie.o 
apache_multipart_buffer.o]
 # TYPEMAPS = [q[C:/Temp/mod_perl-1.28/src/modules/perl/typemap]]
 # VERSION = q[1.2]

ah, of course c/Makefile.PL has a special case for WIN32. Try this: 
G.

OK, that's better, but it now falls over saying don't know how to make 
'dynamic'!

This patch finally fixes it for me:

--- Makefile.PL.orig2001-04-03 20:24:12.0 +0100
+++ Makefile.PL2003-07-31 15:17:03.0 +0100
@@ -18,7 +18,7 @@
WriteMakefile(
   #grr, problems with things finding libapreq.so, sort out later.
   'LINKTYPE' = 'static',
-#   'SKIP' = [qw(dynamic_lib dynamic_bs)],
+   'SKIP' = [qw(dynamic dynamic_lib dynamic_bs)],
   'NAME' = 'libapreq',
   'INC'  = $src-inc,
   'TYPEMAPS'   = $src-typemaps,
@@ -67,6 +67,8 @@
  WriteMakefile('NAME' = 'libapreq',
'TYPEMAPS' = [ $ENV{MP_INC}/typemap ],
'VERSION' = $myVERSION,
+'LINKTYPE' = 'static',
+'SKIP' = [qw(dynamic dynamic_lib dynamic_bs)],
'OBJECT' = @objs,
'INC'  = qq{ -I$ENV{AP_INC} 
-I$ENV{AP_INC}/../os/win32 -I$ENV{MP_INC} },
 );

Steve

Apache-print() problem with UTF-8 data in Perl 5.8

2003-07-29 Thread Steve Hay

Is anybody going to take a serious look at the problem that I previously 
reported with Apache-print()'s handling of UTF-8 data in Perl 5.8?

The patch that I sent 
(http://marc.theaimsgroup.com/?l=apache-modperlm=105912130001046w=2) 
seems to fix it for me on Windows as long as I've got perl #20203 
incorporated.  Does it work on other platforms?

The #ifdef version-checks need a little work: on Windows (and other 
platforms [-- which ones?] that rely on Perl's makedef.pl to get symbols 
exported from the Perl library) you need perl-5.8.1; on other platforms 
the test for perl-5.8.0 should be fine.  The brokenness of 
Apache-print() under perl-5.8.0 on Windows et al would also need 
documenting somewhere since it can't be fixed properly.

Maybe it's just easier to change the version-checks to 5.8.1 for all 
platforms, and document the broken behaviour under 5.8.0?

Steve

Re: Apache-print() problem with UTF-8 data in Perl 5.8

2003-07-29 Thread Steve Hay

Stas Bekman wrote:

Steve Hay wrote:

Is anybody going to take a serious look at the problem that I 
previously reported with Apache-print()'s handling of UTF-8 data in 
Perl 5.8?


Steve,

At the moment I'm busy fixing things for p5.8.1 for which mod_perl 2.0 
is one of the showstoppers and Jarkko really wants to release 5.8.1 now.
Is there a problem with mod_perl 1.28 under the forthcoming perl 5.8.1 
as well?  I just tried out Jarkko's latest release 
(http://www.iki.fi/jhi/[EMAIL PROTECTED]), and I found that mod_perl 1.28 
doesn't work with it.  (And that's without my patch -- just a plain 
mp1.28 straight out of the box.)

It built OK (after I installed various prerequisites -- HTML-Tagset, 
HTML-Parser, libwin32, LWP, URI), but the test suite doesn't run at all.

Manually running C:\apache\apache.exe -f 
C:\Temp\mod_perl-1.28\t\conf\httpd.conf -t just causes Windows to throw 
up an Application Error window.

Once finished (should be soon) I will take care of all the outstanding 
issues, and there are quite a few. I apologize for not following up on 
those. 
No problem.  Just wanted to check that it hadn't been forgotten.

Steve

Re: Apache-print() problem with UTF-8 data in Perl 5.8

2003-07-29 Thread Steve Hay

Randy Kobes wrote:

On Tue, 29 Jul 2003, Steve Hay wrote:

 

Is anybody going to take a serious look at the problem that I previously
reported with Apache-print()'s handling of UTF-8 data in Perl 5.8?
The patch that I sent
(http://marc.theaimsgroup.com/?l=apache-modperlm=105912130001046w=2)
seems to fix it for me on Windows as long as I've got perl #20203
incorporated.  Does it work on other platforms?
The #ifdef version-checks need a little work: on Windows (and other
platforms [-- which ones?] that rely on Perl's makedef.pl to get symbols
exported from the Perl library) you need perl-5.8.1; on other platforms
the test for perl-5.8.0 should be fine.  The brokenness of
Apache-print() under perl-5.8.0 on Windows et al would also need
documenting somewhere since it can't be fixed properly.
Maybe it's just easier to change the version-checks to 5.8.1 for all
platforms, and document the broken behaviour under 5.8.0?
   

mod_perl 2 makes two special cases for handling systems that use
export files - Win32 and aix ($^O eq 'aix'). So these might
be the only two one has to worry about in this regard.
These were the only two that Nicholas Clark mentioned when I asked about 
the missing PerlIO_isutf8() on the perl-xs list, so that may well be 
true.  I will double-check with p5p to see if there are any more.

I take
it this is a problem in principle on all platforms running
perl-5.8?
Yes.

If so, what might work is, for all platforms
running 5.8.x, apply the patch, except for Win32 and aix (I'm
not sure of aix), which would require 5.8.1. So something like
#if PERL_VERSION = 8
#if ( defined(WIN32) || defined(_AIX) )  PERL_SUBVERSION = 1

#endif
#endif
And then, as you say, document the broken behaviour under
Win32 (and aix?) for 5.8.0.
 

I agree entirely with your sentiment, but shouldn't the logic be more 
like this:

#if PERL_VERSION = 8  ((!defined(WIN32)  !defined(_AIX)) || 
PERL_SUBVERSION = 1)
...
#endif

Steve

Re: Undocumented behaviour in Apache-print()?

2003-07-25 Thread Steve Hay

Steve Hay wrote:

Stas Bekman wrote:


 I have attempted to shoe-horn this into mod_perl's print() method (in
 src/modules/perl/Apache.xs).  Here's the diff against mod_perl 1.28:
 [Unfortunately, I've had to comment-out the first part of that if
 block, because I got an unresolved external symbol error relating 
to the
 PerlIO_isutf8() function otherwise (which may be because that function
 isn't documented in the perlapio manpage).]

mod_perl 1.x doesn't use perlio, hence you have this problem. adding:

#include perlio.h

should resolve it I think. 


No.  The error was unresolved external symbol, which means that the 
compiler is happy (it evidently has pulled in perlio.h, or something 
else that declares PerlIO_isutf8() as extern ...), but that the 
linker couldn't find the definition of that function.

(Check: If I change PerlIO_isutf8 to PerlIO_isutf (deliberate 
typo) then I get a different error - undefined; assuming extern 
returning int - because now no declaration has been supplied.)

Listing the symbols exported from perl58.lib shows that PerlIO_isutf8 
is *not* one of them.  So where's the definition supposed to come from?

I'll ask about this on the perlxs mailing list, I think. 
Having asked about this, it turns out that the problem was 
PerlIO_isutf8() not being exported from perl58.lib on Windows (and other 
platforms where the symbols to export have to be explicitly listed).

I sent a patch off to p5p which fixes this 
(http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-07/msg01096.html), 
and it has been integrated as #20203.

So presumably this will not be a problem in the upcoming perl-5.8.1, but 
how do we cope with the perl-5.8.0 case?

I've attached a new patch (against mod_perl-1.28) which (I believe) 
fixes the UTF-8 problem, but it won't build on Windows with perl-5.8.0 
without #20203.

Steve
--- Apache.xs.orig  2003-06-06 12:31:10.0 +0100
+++ Apache.xs   2003-07-18 08:47:59.0 +0100
@@ -1119,11 +1119,27 @@
SV *sv = sv_newmortal();
SV *rp = ST(0);
SV *sendh = perl_get_sv(Apache::__SendHeader, TRUE);
+#if PERL_VERSION = 8
+   PerlIO *fp = IoOFP(GvIOp(defoutgv));
+#endif
 
if(items  2)
do_join(sv, sv_no, MARK+1, SP); /* $sv = join '', @_[1..$#_] */
 else
sv_setsv(sv, ST(1));
+#if PERL_VERSION = 8
+   if (PerlIO_isutf8(fp)) {
+   if (!SvUTF8(sv))
+   sv_utf8_upgrade(sv = sv_mortalcopy(sv));
+   }
+   else if (DO_UTF8(sv)) {
+   if (!sv_utf8_downgrade((sv = sv_mortalcopy(sv)), TRUE)
+ckWARN_d(WARN_UTF8))
+   {
+   Perl_warner(aTHX_ packWARN(WARN_UTF8), Wide character in print);
+   }
+   }
+#endif
 
PUSHMARK(sp);
XPUSHs(rp);
@@ -1176,6 +1192,20 @@
int sent = 0;
 SV *sv = SvROK(ST(i))  (SvTYPE(SvRV(ST(i))) == SVt_PV) ?
  (SV*)SvRV(ST(i)) : ST(i);
+#if PERL_VERSION = 8
+   PerlIO *fp = IoOFP(GvIOp(defoutgv));
+   if (PerlIO_isutf8(fp)) {
+   if (!SvUTF8(sv))
+   sv_utf8_upgrade(sv = sv_mortalcopy(sv));
+   }
+   else if (DO_UTF8(sv)) {
+   if (!sv_utf8_downgrade((sv = sv_mortalcopy(sv)), TRUE)
+ckWARN_d(WARN_UTF8))
+   {
+   Perl_warner(aTHX_ packWARN(WARN_UTF8), Wide character in print);
+   }
+   }
+#endif
buffer = SvPV(sv, len);
 #ifdef APACHE_SSL
 while(len  0) {

Re: Undocumented behaviour in Apache-print()?

2003-07-16 Thread Steve Hay

Stas Bekman wrote:

Steve Hay wrote:

It's only Perl 5.8 that has the special UTF-8 flag which the 
functions above all operate with respect to.  If a Perl variable 
contains a sequence of bytes that make up a valid UTF-8 character, 
but the string is not flagged with Perl's special flag, then Perl's 
built-in print() doesn't do this automatic conversion anyway.


Yes.

Apps wanting to handle utf will need to 'require 5.008;' as in your 
example.

IOW,

   print Content-type: text/plain\n\n;
   $a = \xC3\xBC;
   print $a;
retrieved from a mod_cgi server produces (via od -b / od -c):

   000 303 274
   002


yup, because you need to add utf8::decode($a); before printing $a. 
Which your version does as well. 
(Indeed.  I meant it as example of how Perl's (5.8's) print() doesn't do 
the conversion on strings that are not *flagged* as UTF-8, even when 
they make valid UTF-8.)



Perl 5.6 and older don't have the UTF-8 flag and hence don't do any 
automatic conversion via print().  Therefore, mod_perl's print() 
should not have the difference from Perl's print() that exists in 
5.8, so no change should be required.

Sure enough, looking at the doio.c source file in Perl 5.6.1, the 
entire chunk of code that I half-inched above is not present.


So you suggest that we copy this functionality from Perl. So if need 
to #ifdef it for 5.8.0. 
So I'll add

#if PERL_VERSION = 8
...
#endif
around the code that I've added.



 I have attempted to shoe-horn this into mod_perl's print() method (in
 src/modules/perl/Apache.xs).  Here's the diff against mod_perl 1.28:
 [Unfortunately, I've had to comment-out the first part of that if
 block, because I got an unresolved external symbol error relating to 
the
 PerlIO_isutf8() function otherwise (which may be because that function
 isn't documented in the perlapio manpage).]

 --- Apache.xs.orig2003-06-06 12:31:10.0 +0100
 +++ Apache.xs2003-07-15 12:20:42.0 +0100
 @@ -1119,12 +1119,25 @@
 SV *sv = sv_newmortal();
 SV *rp = ST(0);
 SV *sendh = perl_get_sv(Apache::__SendHeader, TRUE);
 +/*PerlIO *fp = PerlIO_stdout();*/

 if(items  2)
 do_join(sv, sv_no, MARK+1, SP); /* $sv = join '', 
@_[1..$#_] */
 else
 sv_setsv(sv, ST(1));

 +/*if (PerlIO_isutf8(fp)) {
 +if (!SvUTF8(sv))
 +sv_utf8_upgrade(sv = sv_mortalcopy(sv));
 +}
 +else*/ if (DO_UTF8(sv)) {
 +if (!sv_utf8_downgrade((sv = sv_mortalcopy(sv)), TRUE)
 + ckWARN_d(WARN_UTF8))
 +{
 +Perl_warner(aTHX_ packWARN(WARN_UTF8), Wide character in 
print);
 +}
 +}
 +
 PUSHMARK(sp);
 XPUSHs(rp);
 XPUSHs(sv);

 Besides the problem with PerlIO_isutf8(),

mod_perl 1.x doesn't use perlio, hence you have this problem. adding:

#include perlio.h

should resolve it I think. 
No.  The error was unresolved external symbol, which means that the 
compiler is happy (it evidently has pulled in perlio.h, or something 
else that declares PerlIO_isutf8() as extern ...), but that the linker 
couldn't find the definition of that function.

(Check: If I change PerlIO_isutf8 to PerlIO_isutf (deliberate typo) 
then I get a different error - undefined; assuming extern returning 
int - because now no declaration has been supplied.)

Listing the symbols exported from perl58.lib shows that PerlIO_isutf8 is 
*not* one of them.  So where's the definition supposed to come from?

I'll ask about this on the perlxs mailing list, I think.



 there are other problems that
 spring to my mind straight away with this:
 - is getting the PerlIO * for STDOUT to right thing to be doing anyway?
PerlIO *fp = IoOFP(GvIOp(defoutgv)) 
Seems to work OK for me.  What's defoutgv?



 - if items  2, do we need to handle the UTF8-ness of each of those
 items individually before we join them?
I'm not sure, how perl handles this? 
Struggling as best as I can to read pp_print() in Perl's pp_hot.c, it 
looks like Perl calls do_print() (which contains the UTF-8 handling that 
I've stolen) for each item in the list that is passed to it.

Considering this more, I think that it probably isn't an issue: if you 
have two variables in Perl, one of which is flagged UTF-8 and the other 
of which isn't, then when you concatenate them, the whole is upgraded 
to flagged UTF-8 anyway.

However, it has occurred to me that I've missed out adding the UTF-8 
handling to half of mod_perl's print() method!

The method is split into two halves:

   if (!mod_perl_sent_header(r, 0)) {
   ...
   } else {
   ...
   }
and I've only handled the first half!

The first half joins all of the items together and then calls 
send_cgi_header().  That outputs everything down to the first blank line 
(i.e. all the headers), then sets the sent headers flag and recurses 
on $r-print().  Next time around, we'll enter the second half, which 
simply calls write_client().

If we've already been through the first half then the UTF-8 conversion 
will have been applied already

Re: Undocumented behaviour in Apache-print()?

2003-07-15 Thread Steve Hay

Hi Stas,

Stas Bekman wrote:

Steve Hay wrote:

Hi,

I've just spent quite a while tracking down a problem with a web page 
generated by a mod_perl program in which 8-bit ISO-8859-1 characters 
were not being shown properly.  The software runs via 
Apache::Registry, and works fine under mod_cgi.

It turns out that the problem is due to a difference in behaviour 
between Perl's built-in print() function in Perl 5.8.0+ and the 
Apache-print() method that mod_perl overrides it with.  I've 
consulted the documentation on the mod_perl website, and could find 
no mention of the difference.  If my conclusions below are correct 
then this information may well be worth adding.


[the rest of the very detailed analysis has been snipped]

5.8.0 is a pretty new perl version, which provides the new 
functionality, and it seems that hardly anybody has been using the UTF 
stuff with mod_perl.
5.8.0 is actually a couple of days short of being one year old (happy 
birthday!), which is increasingly not that new any more.  5.8.1 should 
be out soon too.

As for hardly anybody using UTF8 stuff with mod_perl... I didn't think 
that I was until I realised that most XML parsers (certainly the two 
that I most uses -- XML::LibXML and XML::DOM) return all their data in 
Perl's internal UTF-8 format!  Then the penny dropped that I was 
actually using it rather a lot :-)

So I suppose you are the first one to hit the problem. Certainly we 
need to update mod_perl to handle this correctly. Would you be 
interested to try to make Apache-print() do the right thing?
Hmm.  We really need somebody who understands the internals of Perl and 
mod_perl better than me, but here's a first stab at it:

The Perl source code contains a pp_print() function in pp_hot.c which 
I presume is basically CORE::print().  It makes use of a do_print() 
function.  I think that function comes from doio.c, although it's 
actually called Perl_do_print() there.  That function does some stuff 
with the UTF-8 flag, which I guess is the sort of thing that we're 
after.  Here's a chunk of Perl_do_print() from Perl 5.8.0:

   if (PerlIO_isutf8(fp)) {
   if (!SvUTF8(sv))
   sv_utf8_upgrade(sv = sv_mortalcopy(sv));
   }
   else if (DO_UTF8(sv)) {
   if (!sv_utf8_downgrade((sv = sv_mortalcopy(sv)), TRUE)
ckWARN_d(WARN_UTF8))
   {
   Perl_warner(aTHX_ packWARN(WARN_UTF8), Wide character in print);
   }
   }
I think what this does is look to see if the fp (a PerlIO *) has the 
:utf8 encoding layer.  If so, then it upgrades the sv to UTF8 (which 
is always possible).  If not, then it looks to see if the bytes pragma 
is enabled.  If not, then it downgrades the sv from UTF8 (which is not 
always possible -- if that fails and the UTF8 warnings category is 
enabled then it outputs the good ol' Wide character in print warning).

I have attempted to shoe-horn this into mod_perl's print() method (in 
src/modules/perl/Apache.xs).  Here's the diff against mod_perl 1.28:  
[Unfortunately, I've had to comment-out the first part of that if 
block, because I got an unresolved external symbol error relating to the 
PerlIO_isutf8() function otherwise (which may be because that function 
isn't documented in the perlapio manpage).]

--- Apache.xs.orig2003-06-06 12:31:10.0 +0100
+++ Apache.xs2003-07-15 12:20:42.0 +0100
@@ -1119,12 +1119,25 @@
SV *sv = sv_newmortal();
SV *rp = ST(0);
SV *sendh = perl_get_sv(Apache::__SendHeader, TRUE);
+/*PerlIO *fp = PerlIO_stdout();*/
if(items  2)
do_join(sv, sv_no, MARK+1, SP); /* $sv = join '', @_[1..$#_] */
else
sv_setsv(sv, ST(1));
+/*if (PerlIO_isutf8(fp)) {
+if (!SvUTF8(sv))
+sv_utf8_upgrade(sv = sv_mortalcopy(sv));
+}
+else*/ if (DO_UTF8(sv)) {
+if (!sv_utf8_downgrade((sv = sv_mortalcopy(sv)), TRUE)
+ ckWARN_d(WARN_UTF8))
+{
+Perl_warner(aTHX_ packWARN(WARN_UTF8), Wide character in print);
+}
+}
+
PUSHMARK(sp);
XPUSHs(rp);
XPUSHs(sv);
Besides the problem with PerlIO_isutf8(), there are other problems that 
spring to my mind straight away with this:
- is getting the PerlIO * for STDOUT to right thing to be doing anyway?
- if items  2, do we need to handle the UTF8-ness of each of those 
items individually before we join them?
- we need to code this in such a way as to remain backwards compatible 
with older Perls.

Anyway, it's a start.

If not, we should log it in the STATUS file and hopefully someone will 
have the time and inclination to solve it. 
Hopefully the above stab at it will encourage somebody to have a serious 
look.



In any case a simple test that reproduces the problem will be needed. 
This test program reproduces the problem:

   use 5.008;
   use Encode;
   print Content-type: text/plain\n\n, decode('iso-8859-1', 'ü');
Use LWP's get program to get that from an Apache/mod_cgi setup, run it 
through UNIX's od -c (get http://localhost/cgi-bin/test.pl | od

Re: Undocumented behaviour in Apache-print()?

2003-07-15 Thread Steve Hay

Stas Bekman wrote:

I have attempted to shoe-horn this into mod_perl's print() method (in 
src/modules/perl/Apache.xs).  Here's the diff against mod_perl 
1.28:  [Unfortunately, I've had to comment-out the first part of that 
if block, because I got an unresolved external symbol error 
relating to the PerlIO_isutf8() function otherwise (which may be 
because that function isn't documented in the perlapio manpage).]

--- Apache.xs.orig2003-06-06 12:31:10.0 +0100
+++ Apache.xs2003-07-15 12:20:42.0 +0100
@@ -1119,12 +1119,25 @@
SV *sv = sv_newmortal();
SV *rp = ST(0);
SV *sendh = perl_get_sv(Apache::__SendHeader, TRUE);
+/*PerlIO *fp = PerlIO_stdout();*/
if(items  2)
do_join(sv, sv_no, MARK+1, SP); /* $sv = join '', @_[1..$#_] */
else
sv_setsv(sv, ST(1));
+/*if (PerlIO_isutf8(fp)) {
+if (!SvUTF8(sv))
+sv_utf8_upgrade(sv = sv_mortalcopy(sv));
+}
+else*/ if (DO_UTF8(sv)) {
+if (!sv_utf8_downgrade((sv = sv_mortalcopy(sv)), TRUE)
+ ckWARN_d(WARN_UTF8))
+{
+Perl_warner(aTHX_ packWARN(WARN_UTF8), Wide character in 
print);
+}
+}
+
PUSHMARK(sp);
XPUSHs(rp);
XPUSHs(sv);

Besides the problem with PerlIO_isutf8(), there are other problems 
that spring to my mind straight away with this:
- is getting the PerlIO * for STDOUT to right thing to be doing anyway?
- if items  2, do we need to handle the UTF8-ness of each of those 
items individually before we join them?
- we need to code this in such a way as to remain backwards 
compatible with older Perls.


looks like this is the main question. Do we handle utf8 only for perl 
5.8? 
It's only Perl 5.8 that has the special UTF-8 flag which the functions 
above all operate with respect to.  If a Perl variable contains a 
sequence of bytes that make up a valid UTF-8 character, but the string 
is not flagged with Perl's special flag, then Perl's built-in print() 
doesn't do this automatic conversion anyway.

IOW,

   print Content-type: text/plain\n\n;
   $a = \xC3\xBC;
   print $a;
retrieved from a mod_cgi server produces (via od -b / od -c):

   000 303 274
   002
Perl 5.6 and older don't have the UTF-8 flag and hence don't do any 
automatic conversion via print().  Therefore, mod_perl's print() should 
not have the difference from Perl's print() that exists in 5.8, so no 
change should be required.

Sure enough, looking at the doio.c source file in Perl 5.6.1, the 
entire chunk of code that I half-inched above is not present.

Steve

Undocumented behaviour in Apache-print()?

2003-07-11 Thread Steve Hay

Hi,

I've just spent quite a while tracking down a problem with a web page 
generated by a mod_perl program in which 8-bit ISO-8859-1 characters 
were not being shown properly.  The software runs via Apache::Registry, 
and works fine under mod_cgi.

It turns out that the problem is due to a difference in behaviour 
between Perl's built-in print() function in Perl 5.8.0+ and the 
Apache-print() method that mod_perl overrides it with.  I've consulted 
the documentation on the mod_perl website, and could find no mention of 
the difference.  If my conclusions below are correct then this 
information may well be worth adding.

Under Perl 5.8.0, if a string stored in Perl's internal UTF-8 format is 
passed to print() then by default it will be converted to the machine's 
native 8-bit character set on output to STDOUT.  In my case, this is 
exactly as if I had called binmode(STDOUT, ':encoding(iso-8859-1)') 
before the print().  (If any characters in the UTF-8 string are not 
representable in ISO-8859-1 then a Wide character in print() warning 
will be emitted, and the bytes that make up that UTF-8 character will be 
output.)

However, mod_perl's Apache-print() method does not perform this 
automatic conversion.  It simply prints the bytes that make up each 
UTF-8 character (i.e. it outputs the UTF-8 string as UTF-8), exactly as 
if you had called binmode(STDOUT, ':utf8') before Apache-print().  (No 
Wide character in print() warnings are produced for charcaters with 
code points  0xFF either.)

The test program below illustrates this difference:

   use 5.008;
   use strict;
   use warnings;
   use Encode;
   my $cset = 'ISO-8859-1';
   #my $cset = 'UTF-8';
   print Content-type: text/html; charset=$cset\n\n;
   print EOT;
   html
   head
   meta http-equiv=Content-type content=text/html; charset=$cset
   /head
   body
   EOT
   # $str is stored in Perl's internal UTF-8 format.
   my $str = Encode::decode('iso-8859-1', 'Zurück');
   print p$str/p\n;
   print EOT;
   /body
   /html
   EOT
Running under mod_cgi (using Perl's built-in print() function) the UTF-8 
encoded data in $str is converted to ISO-8859-1 on-the-fly by the 
print(), and the end-user will see the intended output when $cset is 
ISO-8859-1.  (Changing $cset to UTF-8 causes the ü to be replaced with ? 
in my web browser because the ü which is output is not a valid UTF-8 
character (which the output is labelled as).)

Running under mod_perl (with Perl's built-in print() function now 
overridden by the Apache-print() method) the UTF-8 encoded data in $str 
is NOT converted to ISO-8859-1 on-the-fly as it is printed, and the 
end-user will see the two bytes that make up the UTF-8 representation of 
ü when $cset is ISO-8859-1.  Changing $cset to UTF-8 in this case 
fixes it, because the output stream in this case happens to be valid 
UTF-8 all the way through.

There are two solutions to this:

1. To use $cset = 'ISO-8859-1': Explicitly convert the UTF-8 data in 
$str to ISO-8859-1 yourself before sending it to print(), rather than 
relying on print() to do that for you.  This is, in general, not 
possible (not all characters in the UTF-8 string may be representable in 
ISO-8859-1), but for HTML output we can arrange for Encode::encode to 
convert any non-representable charcaters to their HTML character references:

   $str = Encode::encode('iso-8859-1', $str, Encode::FB_HTMLCREF);

2. To use $cset = 'UTF-8': Output UTF-8 directly, ensuring that *all* 
outgoing data is UTF-8 by adding an appropriate layer on STDOUT:

   binmode STDOUT, ':utf8';

The second method here is generally to be preferred, but in the old 
software that I was experiencing problems with, I was not able to add 
the utf8 layer to STDOUT reliably (the data was being output from a 
multitude of print() statements scattered in various places), so I stuck 
with the first method.  I believed that it should work without the 
explicit encoding to ISO-8859-1 because I was unaware that mod_perl's 
print() override removed Perl's implicit encoding behaviour.  Actually, 
the explicit encoding above is better anyway because it also handles 
characters that can't be encoded to ISO-8859-1, but nevertheless I think 
the difference in mod_perl's print() is still worth mentioning in the 
documentation somewhere.

Cheers,

Steve

Re: [ANNOUNCE] mod_perl-1.28

2003-07-04 Thread Steve Hay

Hi Randy,

Randy Kobes wrote:

On Thu, 3 Jul 2003, Steve Hay wrote:

 

Philippe M. Chiasson wrote:
   

The URL
  http://perl.apache.org/dist/mod_perl-1.28.tar.gz
has entered CPAN
 

I still get the same test failures that I reported before when
RC2 was announced:
modules/request...FAILED tests 3-8
   Failed 6/10 tests, 40.00% okay
Setup: Windows XP, Perl 5.8.0, Apache 1.3.27, Apache-Test 1.03,
libapreq-1.2 (built/installed *after* mod_perl 1.28).
I used to have All tests successful under mp-1.27.
   

This may be a problem with libapreq - the mod_perl
t/modules/request.t tests, among other things, the sizes involved
with file uploads. The error log you posted earlier reported a
difference in these sizes for three (text) files, with a binary
(gif) file apparently OK (interestingly, with a patch I posted
earlier to allow Win32 ActivePerl 8xx to be used with mod_perl 1
(with LARGE_FILES support), I get a failure with the gif file,
but not the text files). Anyway, could you see if the following
helps (applied to the libapreq sources)? For me, this allows all
the mod_perl t/modules/request tests to pass.
Yes, this fixes it for me.

All the mod_perl 1.28 tests now pass (and all the libapreq 1.2 tests 
still pass as well).

Thanks!

Steve


Index: Request/Request.xs
===
RCS file: /home/cvs/httpd-apreq/Request/Request.xs,v
retrieving revision 1.36
diff -u -r1.36 Request.xs
--- Request/Request.xs  25 Jun 2003 07:59:37 -  1.36
+++ Request/Request.xs  4 Jul 2003 05:32:59 -
@@ -533,7 +533,7 @@
if (fd  0)
XSRETURN_UNDEF;
-if ( !(RETVAL = PerlIO_fdopen(fd, r)) )
+if ( !(RETVAL = PerlIO_fdopen(fd, rb)) )
XSRETURN_UNDEF;
#else
if (  ( RETVAL = PerlIO_importFILE(fp,0) ) == NULL  )
@@ -558,7 +558,7 @@
PerlIO *fp;
fd = PerlLIO_dup(fd);
-   if (!(fp = PerlIO_fdopen(fd, r))) {
+if (!(fp = PerlIO_fdopen(fd, rb))) {
PerlLIO_close(fd);
croak(fdopen failed!);
}

The first r - rb change (which affects the mod_perl tests)
is only relevant for Perl  5.7, which is why this problem didn't
arise on Win32 with Perl-5.6. Also, I think this r - rb
doesn't have any effect on Unix, but I haven't tested this.

Re: [ANNOUNCE] mod_perl-1.28

2003-07-03 Thread Steve Hay

Hi Philippe,

Philippe M. Chiasson wrote:

The URL

   http://perl.apache.org/dist/mod_perl-1.28.tar.gz

has entered CPAN

I still get the same test failures that I reported before when RC2 was 
announced:

modules/request...FAILED tests 3-8
   Failed 6/10 tests, 40.00% okay
Setup: Windows XP, Perl 5.8.0, Apache 1.3.27, Apache-Test 1.03, 
libapreq-1.2 (built/installed *after* mod_perl 1.28).

I used to have All tests successful under mp-1.27.

(I note that Apache::Reload didn't make it in either; I thought the plan 
was to put a backport of the version from mp2 into it?)

Steve

Re: [mp1] 1.28 release candidate #2

2003-06-25 Thread Steve Hay

Hi Randy,

Randy Kobes wrote:

On Tue, 24 Jun 2003, Steve Hay wrote:

 

Philippe M. Chiasson wrote:

   

On Tue, 2003-06-24 at 23:00, Steve Hay wrote:

 

Philippe M. Chiasson wrote:

   

Now bringing you the second mod_perl 1.28 release candidate.
[snip]
 

Windows XP, Apache 1.3.27, Perl 5.8.0:

Failed Test   Stat Wstat Total Fail  Failed  List of Failed
---
modules/request.t   106  60.00%  3-8
   

Is it possible that you have an older version of
Apache::Request lying around that was not recompiled against
this new mod_perl ? (hapenned to me more than once)
 

I did initially have libapreq-1.1 compiled against mp-1.27.
I've now tried 1.2 compiled against the new mod_perl, and I
still get the same result.  (I have Apache-Test 1.03 in place,
if that's at all relevant.)
   

Did the libapreq-1.2 tests pass?

Yes -- all successful.

Also, what's your 'perl -V'? mod_perl 1 with ActivePerl 8xx
(based on perl-5.8) doesn't build, due to the addition of
LARGE_FILES support, so you must have disabled that.
Yes, you're right - I've built Perl myself using ActivePerl 806 sources, 
and I've disabled USE_LARGE_FILES (and also USE_MULTI, USE_ITHREADS and 
USE_IMP_SYS, and I've enabled PERL_MALLOC and PERL_DEBUGGING_MSTATS). 
Here's my perl -V:

Summary of my perl5 (revision 5 version 8 subversion 0) configuration:
 Platform:
   osname=MSWin32, osvers=4.0, archname=MSWin32-x86-perlio
   uname=''
   config_args='undef'
   hint=recommended, useposix=true, d_sigaction=undef
   usethreads=undef use5005threads=undef useithreads=undef 
usemultiplicity=undef
   useperlio=define d_sfio=undef uselargefiles=undef usesocks=undef
   use64bitint=undef use64bitall=undef uselongdouble=undef
   usemymalloc=y, bincompat5005=undef
 Compiler:
   cc='cl', ccflags ='-nologo -Gf -W3 -MD -DNDEBUG -O1 -DWIN32 
-D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT  -DPERL_DEBUGGING_MSTATS 
-DUSE_PERLIO -DPERL_MSVCRT_READFIX',
   optimize='-MD -DNDEBUG -O1',
   cppflags='-DWIN32'
   ccversion='', gccversion='', gccosandvers=''
   intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
   d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
   ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', 
lseeksize=4
   alignbytes=8, prototype=define
 Linker and Libraries:
   ld='link', ldflags ='-nologo -nodefaultlib -release  
-libpath:C:\perl5\lib\CORE  -machine:x86'
   libpth=C:\PROGRA~1\MICROS~2\VC98\lib C:\openssl\lib
   libs=libeay32.lib  oldnames.lib kernel32.lib user32.lib gdi32.lib 
winspool.lib  comdlg32.lib advapi32.lib shell32.lib ole32.lib 
oleaut32.lib  netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib  
version.lib odbc32.lib odbccp32.lib msvcrt.lib
   perllibs=libeay32.lib  oldnames.lib kernel32.lib user32.lib 
gdi32.lib winspool.lib  comdlg32.lib advapi32.lib shell32.lib ole32.lib 
oleaut32.lib  netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib  
version.lib odbc32.lib odbccp32.lib msvcrt.lib
   libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl58.lib
   gnulibc_version='undef'
 Dynamic Linking:
   dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
   cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -release  
-libpath:C:\perl5\lib\CORE  -machine:x86'

Characteristics of this binary (from libperl):
 Compile-time options:
 Built under MSWin32
 Compiled at May  1 2003 14:48:19
 @INC:
   C:/perl5/lib
   C:/perl5/site/lib
   .

Re: [mp1] 1.28 release candidate #2

2003-06-24 Thread Steve Hay

Philippe M. Chiasson wrote:

Now bringing you the second mod_perl 1.28 release candidate.
[snip]
Please give this release a spin and report back any problems or failed tests to:
[EMAIL PROTECTED] as soon as possible. The more platforms  configurations, the
merrier!
Windows XP, Apache 1.3.27, Perl 5.8.0:

Failed Test   Stat Wstat Total Fail  Failed  List of Failed
---
modules/request.t   106  60.00%  3-8
Philippe: Is the Apache::Reload stuff not going to make it into 1.28?  I 
think it would be well worth waiting a little longer for 1.28 if that 
could make it in.

Steve

Re: [mp1] 1.28 release candidate #2

2003-06-24 Thread Steve Hay

Philippe M. Chiasson wrote:

On Tue, 2003-06-24 at 23:00, Steve Hay wrote:
 

Philippe M. Chiasson wrote:

   

Now bringing you the second mod_perl 1.28 release candidate.
[snip]
Please give this release a spin and report back any problems or failed tests to:
[EMAIL PROTECTED] as soon as possible. The more platforms  configurations, the
merrier!
 

Windows XP, Apache 1.3.27, Perl 5.8.0:

Failed Test   Stat Wstat Total Fail  Failed  List of Failed
---
modules/request.t   106  60.00%  3-8
   

Is it possible that you have an older version of Apache::Request lying
around that was not recompiled against this new mod_perl ? (hapenned to
me more than once)
I did initially have libapreq-1.1 compiled against mp-1.27.  I've now 
tried 1.2 compiled against the new mod_perl, and I still get the same 
result.  (I have Apache-Test 1.03 in place, if that's at all relevant.)

What's in the error_log?

Loads of stuff -- I've attached it (gzipped).

 

Philippe: Is the Apache::Reload stuff not going to make it into 1.28?  I 
think it would be well worth waiting a little longer for 1.28 if that 
could make it in.
   

Well, maybe, maybe not. In any case, I am planning to go at a mp 1.29
release fairly soon after 1.28 hits the decks. There are still quite a
few itty-gritty bugs I want to hammer out of mod_perl 1, but that are
yet a bit too touchy to roll up in a release without letting the CVS
user some time to see it work/break for them.
If you feel like submitting a back-port of Apache::Reload (with or
without my new namespace deletion code), that has a few decents tests
for it and works with perl 5.5.3 up to bleadperl, I would be happy to
slip it into mp 1.28 with a version of 1.0_0 or similar to make sure
CPAN won't be fooled into installing it for now. Just noticed there is
Apache::Reload 0.07 on CPAN, so it would be safe.
The last patch that I submitted 
(http://marc.theaimsgroup.com/?l=apache-modperl-devm=105595499417788w=2) 
almost fits the bill -- just remove the if (MOD_PERL2) stuff at the 
top for a mp1-only version.

However, that uses the B module, which is only available from 5.005_03 
up.  That's all that you're asking for above, but when I previously 
pointed out that the current mp1 Makefile.PL specifies 5.003_97 up (in 
general, different on Win32/cygwin), you said that you didn't want to 
have to up the minimum requirement to 5.005_03.

I also currently have no idea how to write tests for Apache modules and 
I'm unlikely to learn in the next couple of days, so unless you're happy 
with a 5.005_03 requirement for Apache::Reload and either don't mind 
having no tests or else can write some yourself then it looks like I'll 
have to wait until 1.29.

Steve

I guess for now the simplest thing would be to _strictly_ backwards port
Apache::Reload with no mp2 specific code in there, just so it can be
shipped in 1.28, then in the 1.29-dev cycle, I can worry about getting
it either on CPAN or synced between both mp1 and mp2, as per the ongoign
discussion with you and Stas on the matter.
So, if you feel you can whip up a complete patch within the next few
days, go for it. Otherwise, I'll delay this for inclusion in 1.29 (and
remember, I would target that one quite soon after 1.28)
Gozer out.

 

Steve
   





mod_perl_error_log.gz
Description: GNU Zip compressed data

RE: Building mod-perl 2 for cygwin

2003-02-19 Thread Steve Baldwin

Unfortunately, I get the same (as far as I can see) result.  Here's my
latest perl -V ...

[perl-5.8.0]$ perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
  Platform:
osname=cygwin, osvers=1.3.19(0.7132),
archname=cygwin-thread-multi-64int
uname='cygwin_nt-5.1 au-stb-mobile 1.3.19(0.7132) 2003-01-23 21:31
i686 unkn
own unknown cygwin '
config_args='-Duse64bitint -Doptimize=-O2 -Dman3ext=3pm
-Dusemultiplicity -D
usethreads -Duselargefiles'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define
usemultiplicity=de
fine
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=define use64bitall=undef uselongdouble=undef
usemymalloc=y, bincompat5005=undef
  Compiler:
cc='gcc', ccflags ='-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing',
optimize='-O2',
cppflags='-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing'
ccversion='', gccversion='3.2 20020927 (prerelease)',
gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long long', ivsize=8, nvtype='double', nvsize=8,
Off_t='off_t', lsee
ksize=4
alignbytes=8, prototype=define
  Linker and Libraries:
ld='ld2', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /usr/lib /lib
libs=-lgdbm -ldb -lcrypt -lutil
perllibs=-lcrypt -lutil
libc=/usr/lib/libc.a, so=dll, useshrplib=true, libperl=libperl.a
gnulibc_version=''
  Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
cccdlflags=' ', lddlflags=' -L/usr/local/lib'


Characteristics of this binary (from libperl): 
  Compile-time options: MULTIPLICITY USE_ITHREADS USE_64_BIT_INT
USE_LARGE_FILES
 PERL_IMPLICIT_CONTEXT
  Built under cygwin
  Compiled at Feb 19 2003 20:16:49
  %ENV:
CYGWIN=
  @INC:
/cygdrive/d/perldev
/usr/local/lib/perl5/5.8.0/cygwin-thread-multi-64int
/usr/local/lib/perl5/5.8.0
/usr/local/lib/perl5/site_perl/5.8.0/cygwin-thread-multi-64int
/usr/local/lib/perl5/site_perl/5.8.0
/usr/local/lib/perl5/site_perl
.

-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, 19 February 2003 10:07 AM
To: Steve Baldwin
Cc: [EMAIL PROTECTED]
Subject: Re: Building mod-perl 2 for cygwin


Steve Baldwin wrote:
 OK, I've rebuilt my perl using the following options ...
 
 ./Configure -de -Duse64bitint -Doptimize=-O2 -Dman3ext=3pm
 
 (to try to keep as similar as possible to packaged perl, but without 
 the threads stuff).  I also tried with simply
 
 ./Configure -des
 
 With exactly the same result.

and if you build with -Dusethreads?

RE: Building mod-perl 2 for cygwin

2003-02-17 Thread Steve Baldwin

Thanks very much for your reply Stas.  Pardon my ignorance, but are you
saying I need to rebuild Perl with different options.  The version of
Perl I'm using is the packaged one I installed with the cygwin install
utility.  If this is the case, could you please a little more
information as to the arguments you recommend to build a version of Perl
that works fine 'standalone', as well as embedded (which I presume is
the case with mod-perl) if that is possible.

Steve

-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]] 
Sent: Monday, 17 February 2003 4:03 PM
Cc: Steve Baldwin; [EMAIL PROTECTED]
Subject: Re: Building mod-perl 2 for cygwin



 We can take two approaches, patch all the places in the code where 
 perl
 context is set explicitly to use #ifdef MULTIPLICITY, rather than
#ifdef 
 USE_THREADS. Or we can refuse to build mod_perl if MULTIPLICITY is 
 enabled without the threads. Of course the first solution is more 
 favorable for users.

I've played a bit with various options and it seems that it's going to
be a 
big trouble to support MULTIPLICITY without USE_THREADS. My suggestion
for now 
is to either rebuild with -Uusemultiplicity or -Dusethreads (less
preferred if 
you don't need threads, but need speed). README.cygwin says:

=item * C-Dusemultiplicity

Multiplicity is required when embedding Perl in a C program and using
more than one interpreter instance.  This works with the Cygwin port.

Though I can't see that this is a required option.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Building mod-perl 2 for cygwin

2003-02-15 Thread Steve Baldwin

I've got Apache2 installed and as far as I can tell, it is functional.
I'm trying to build mod-perl from source (as I couldn't find any
binaries for cygwin).  When I initially ran the command :

perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2

I got errors telling me it couldn't find cygdb-3.1.dll, which I
eventually tracked down to Apache::TextConfig::open_cmd.  I commented
out the line :

local @ENV{ qw(PATH IFS CDPATH ENV BASH_ENV) };

and the errors went away (it was clearing $ENV{PATH} which I think was
causing the error).  However, when I run 'make', I get the following ...

[mod_perl-1.99_08]$ make
cd src/modules/perl  make -f Makefile.modperl
make[1]: Entering directory
`/cygdrive/d/Downloads/mod_perl-1.99_08/src/modules/perl'
gcc -I/cygdrive/d/Downloads/mod_perl-1.99_08/src/modules/perl
-I/cygdrive/d/Downloads/mod_perl-1.99_08/xs -I/usr/local/apache2/include
-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing
-I/usr/lib/perl5/5.8.0/cygwin-multi-64int/CORE -DMOD_PERL -O2  \
-c mod_perl.c  mv mod_perl.o mod_perl.lo
mod_perl.c: In function `modperl_shutdown':
mod_perl.c:10: `my_perl' undeclared (first use in this function)
mod_perl.c:10: (Each undeclared identifier is reported only once
mod_perl.c:10: for each function it appears in.)
mod_perl.c: In function `modperl_hook_post_config':
mod_perl.c:498: `my_perl' undeclared (first use in this function)
mod_perl.c: In function `modperl_response_handler_cgi':
mod_perl.c:771: `my_perl' undeclared (first use in this function)
make[1]: *** [mod_perl.lo] Error 1
make[1]: Leaving directory
`/cygdrive/d/Downloads/mod_perl-1.99_08/src/modules/perl'
make: *** [modperl_lib] Error 2

Here's my perl -V ...

[mod_perl-1.99_08]$ perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
  Platform:
osname=cygwin, osvers=1.3.12(0.5432), archname=cygwin-multi-64int
uname='cygwin_nt-5.0 kmbestst 1.3.12(0.5432) 2002-07-06 02:16 i686
unknown '
config_args='-de -Dmksymlinks -Dusemultiplicity -Duse64bitint
-Doptimize=-O2
 -Dman3ext=3pm'
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=defi
ne
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=define use64bitall=undef uselongdouble=undef
usemymalloc=y, bincompat5005=undef
  Compiler:
cc='gcc', ccflags ='-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing',
optimize='-O2',
cppflags='-DPERL_USE_SAFE_PUTENV -fno-strict-aliasing'
ccversion='', gccversion='3.1.1 20020718 (prerelease)',
gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long long', ivsize=8, nvtype='double', nvsize=8,
Off_t='off_t', lsee
ksize=4
alignbytes=8, prototype=define
  Linker and Libraries:
ld='ld2', ldflags =' -s -L/usr/local/lib'
libpth=/usr/local/lib /usr/lib /lib
libs=-lgdbm -lcrypt -lutil
perllibs=-lcrypt -lutil
libc=/usr/lib/libc.a, so=dll, useshrplib=true, libperl=libperl.a
gnulibc_version=''
  Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' -s'
cccdlflags=' ', lddlflags=' -s -L/usr/local/lib'


Characteristics of this binary (from libperl): 
  Compile-time options: MULTIPLICITY USE_64_BIT_INT USE_LARGE_FILES
PERL_IMPLICI
T_CONTEXT
  Built under cygwin
  Compiled at Jul 24 2002 18:47:09
  %ENV:
CYGWIN=
  @INC:
/cygdrive/d/perldev
/usr/lib/perl5/5.8.0/cygwin-multi-64int
/usr/lib/perl5/5.8.0
/usr/lib/perl5/site_perl/5.8.0/cygwin-multi-64int
/usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/site_perl
.

Thanks for any help

Steve

Re: [mp2]make test fails

2003-01-21 Thread Steve Glaus

On Tue, 21 Jan 2003 16:05:05 +1100
Stas Bekman [EMAIL PROTECTED] wrote:

 Steve Glaus wrote:
  On Mon, 20 Jan 2003 11:29:01 -0500
  [EMAIL PROTECTED] wrote:
  
  
 Hi,
   I'm trying to build mod_perl2 with threads enabled. I recompiled apache with the 
worker mpm, built mod_perl which seemd to build fine.. however, when I go to 'make 
test' it gives me the following error: 
 
 Cannot load /root/cvs/modperl-2.0/src/modules/perl/mod_perl.so into server: 
/root/cvs/modperl-2.0/src/modules/perl/mod_perl.so: undefined symbol: 
Perl_Ipatchlevel_ptr!!!
 
 what's the output of:
 
nm /root/cvs/modperl-2.0/src/modules/perl/mod_perl.so
 
 should be something like:
 
   U Perl_Ipatchlevel_ptr
 
 which is an unresolved symbol, which gets resolved when libperl.so is loaded.
 
 To find out which perl library you have linked against, do:
 
ldd modules/mod_perl.so |grep perl
  libperl.so = 
 /home/stas/perl/blead-ithread/lib/5.9.0/i686-linux-thread-multi/CORE/libperl.so 
 (0x4002e000)
 
 Now you can check whether the symbol is there. in my case:
 
nm 
 /home/stas/perl/blead-ithread/lib/5.9.0/i686-linux-thread-multi/CORE/libperl.so 
 |grep Perl_Ipatch
 0011fa41 T Perl_Ipatchlevel_ptr
 
 Chances are that you are linking against the wrong perl library, which will 
 explain the resolving problem.
 


Ok, I know we're probably going of topic here, but I'll ask anyways.. 

I did what you said...the symbol wasn't there in lipperl.so. So. I rebuilt my perl, 
rebuilt the library, rebuilt my perl again.. I only have one perl library on my 
system.. It still fails. This is a pretty new version of the perl library, so is it 
possible that I need an older one? (libperl-5.8.0). I'm at a bit of a loss as to where 
to go from here. 


Thx.

Steve

Re: [mp2]make test fails

2003-01-20 Thread Steve Glaus

On Mon, 20 Jan 2003 11:29:01 -0500
[EMAIL PROTECTED] wrote:

 Hi,
   I'm trying to build mod_perl2 with threads enabled. I recompiled apache with the 
worker mpm, built mod_perl which seemd to build fine.. however, when I go to 'make 
test' it gives me the following error: 
 
 Cannot load /root/cvs/modperl-2.0/src/modules/perl/mod_perl.so into server: 
/root/cvs/modperl-2.0/src/modules/perl/mod_perl.so: undefined symbol: 
Perl_Ipatchlevel_ptr!!!
 
 


I got the exact same error when I used the prefork model... any thoughts?

Re: [mp2]make test fails

2003-01-20 Thread Steve Glaus

On Mon, 20 Jan 2003 11:29:01 -0500
[EMAIL PROTECTED] wrote:

 Hi,
   I'm trying to build mod_perl2 with threads enabled. I recompiled apache with the 
worker mpm, built mod_perl which seemd to build fine.. however, when I go to 'make 
test' it gives me the following error: 
 
 Cannot load /root/cvs/modperl-2.0/src/modules/perl/mod_perl.so into server: 
/root/cvs/modperl-2.0/src/modules/perl/mod_perl.so: undefined symbol: 
Perl_Ipatchlevel_ptr!!!
 
 
 Does anyone know if it's something I'm doing wrong, or if this is just a temporary 
thing(I got the source for both apache and mod_perl from cvs) I don't really need the 
threads, so I'm going to try to build it with the prefork mpm. I just thought someone 
would like to know..
 
 Thx.


I got the exact same error when I compiled against the prefork model.. Any thoughts?

Re: mp2.0 Apache::Request

2003-01-17 Thread Steve

 In the documentation of nodperl-2.0, I cannot find any references to
 libapreq and $r-param.

correct me if I'm wrong anyone,but I don't think Apache::Request has been
ported to
modperl2 yet..

for now I'm using cgi

Re: modperl : how resolve conflict funtion name in different package

2003-01-16 Thread Steve Piner



Ouimet, Pierre wrote:

 hi!
 
 I have that (by exemple ) :
 
 package pack1.pm
 
 sub get_data {
# ...
 }
 
 package pack2.pm
 
 sub get_data {
# same name, but doing other thing
 }
 
 I don't use export and I have conflict with this 2 package in log file
  (because it detect same function)
 
 In modperl I can't have same function ? That's impossible ! I can't
 beleive that!
 
 Is it possible to allow it ? In apache config or... !?
 
 Tanks a lot in advance! :)
 
 bye
 
 Finder

It sounds like you're not actually using the package statement: pack1.pm
should have a line at the beginning of the file saying 'package pack1;'
and pack2.pm should have a line saying 'package pack2;'

I'm only guessing what the problem is here, as you don't state exactly
what the error message is.


Steve

-- 
Steve Piner
Web Applications Developer
Marketview Limited
http://www.marketview.co.nz

Re: An URL is not Invoking the Anticipated Perl Module [mp2]

2003-01-10 Thread Steve D


To: Stas Bekman [or anyone else];

For the purpose of clarifying the issue, are you saying there is contention
between the two handlers which are declared within the httpd.conf, as it has
been setup in this case?  That is, since a handler has been declared within
by the directory section [/var/www/perl] and another for the location
[/CurrDate], the two handlers are contenting against the one other?
Therefore, in this case, although Location /CurrDate has been defined, the
default handler Directory /var/www/perl is overriding the CurrDate name
space[!?]  Would someone please clarify.

From studying this further, I noticed I forgot to prefix the Location
/CurrDate section with a PerlModule directive.  Consequently, the following
line has been added to the perl.conf file.

PerModule:  MyApache::CurrDate

However, now, with this addition, when starting the Apache the following
exception is genereated:


httpd failed. The error was: Starting httpd: [Fri Jan 10 12:11:15 2003]
[error] Can't locate MyApache/CurrDate.pm in @INC (@INC contains:
/var/www/perl
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/Apache2
/usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl .) at (eval 4)
line 3.


You'll notice from this message, the path does include '/var/www/perl' and
the perl module which is being called is within the
'/var/www/perl/MyApache/' directory.  (For good measure it was also placed
within '/var/www/perl' without a resolution to the run time exception.)
Incidentally, the format of the configuration file which is being used in
this case has been adapted from the article Introducting mod_perl
Handlers.  I've also been using Getting Your Feet Wet with mod_perl.
These resources can be respectfully found at
http://perl.apache.org/docs/2.0/user/handlers/intro.html#What_are_Handlers_
and
http://perl.apache.org/docs/2.0/user/intro/start_fast.html#Handler_Modules I
found these to be very helpful for a newcomer.

This later article was especially beneficial for it connected several
fregmented thoughts together [at least in my own learning curve] into good
concise working document.  In my case, I found it helpful to get a perl
script working [as a first measure] and then proceed to the use of a
response handler.  However, I did run across a problem with how the perl
script name space was defined.  The first example [in the article Getting
Your Feet Wet] would not work when I used the syntax PerlResponseHandler
Modperl::Registry nor PerlResponseHandler Modperl::Registry::handler.
Consequently, I changed the format to PerlHandler
ModPerl::Registry::handler and then my test script was able to run.

Consequently, at this stage, a few questions remain.  1) Since, at least in
this situation, I had to adapt the handler from being PerlResponseHandler to
PerlHandler in order to get the perl scripting to work, does that also mean
the same adaptation will be necessary in order to yield a result from a
reponse handler for the CurrDate.pm module?

2) Once again, how do I instruct Apache to properly locate the CurrDate.pm
file?  [Stas, you may have already given me the answer to this latter
question but more clarity is still needed.]

3) When I include the provision of the line PerModule:  MyApache::CurrDate
within the perl.conf file, Apache throws an exception and failed to start.
Does this line need to be included, or something similiar to it, in order to
Apache to locate the perl module?  [Remember again, in this situation, a
startup.pl script has been delcared in order to provide a library to search
for perl modules.]  The reason I'm asking this question is because the
Introducing mod_perl Handlers article uses this convention while the
Getting Your Feet Wet with mod_perl omitts this line.

The environment is RH 8.0, Apache 2.0.40, mod_perl 1.99_05-dev, and Perl
5.8.0.  [For those who are interested, the original post includes a complete
copy of perf.conf and CurrDate.pm.]

I have been piecing together various web resources but remain uncertain how
to procede.  Further help is appreciated.  Stas, you have already replied to
this once, and to another setup problem for which I was having.  I am
grateful.  Thank you.

Steve D wrote:

 The problem: Apache is generating File does not exist within its
 error.log and the message Object not found (The requested URL was not
 found. Error number 404.) while attempting to call a perl module from a
 brower.
[...]
 Location /CurrDate
 SetHandler per-script
 PerlResponseHandler MyApache::CurrDate
 /Location
s/per-script/perl-script/

SetHandler can't verify at parsing time whether a handler really exists,
it's really a string. So in your case the default handler was handling
that Location.

See: http://httpd.apache.org/docs-2.0/mod/core.html

An URL is not Invoking the Anticipated Perl Module

2003-01-09 Thread Steve D

The problem: Apache is generating File does not exist within its
error.log and the message Object not found (The requested URL was not
found. Error number 404.) while
attempting to call a perl module from a brower.

Since I am new with mod_perl, and somewhat with familiar perl, I must
confess the following problem has baffled me while someone else may quickly see
what is being done wrong.
Appreciation is expressed in advance to anyone who can tell me what the
problem might be or recommends a remedy.

Below youll see the path settings found in the various configurations
files. I have followed the string
of recommendations found in the on-line documentation (from perl.apache.org, etc.) and
but have also made minor adjustments relevant to this particular servers
configuration. I understand that I
am providing some information (not much) which is not relevant to the immediate
problem but can assist to give an overview the operating environment as a
whole.

Here are the details:

Given:

1) The file httpd.conf contains the lines:

ServerRoot "/etc/httpd"

Include conf.d/*.conf

(The presence of this include statement is before the invocation of the
various LoadModules found in most httpd.conf files. Hence, the perl environment
is set early in the Apache initialization process.)

2) and the file /etc/httpd/conf.d/perl.conf contains the
lines:

LoadModule perl_module modules/mod_perl.so
PerlRequire "/var/www/perl/startup.pl"

Alias /perl/ /var/www/perl/
Directory /var/www/perl

SetHandler perl-script

PerlHandler ModPerl::Registry::handler

PerlOptions +ParseHeaders

Options +ExecCGI
/Directory

Location /CurrDate

SetHandler per-script

PerlResponseHandler MyApache::CurrDate
/Location

3) and the file /etc/httpd/perl/startup.pl contains the line:

use lib qw(/var/www/perl);

4) and the file /etc/httpd/perl/MyApache/CurrDate.pm contains the
line:

package MyApache::CurrDate;

then why does /var/httpd/error.log report:

[error] [client 192.168.0.100] File does not exist:
/var/www/html/CurrDate

So, in otherwords, why is does the URL //192.168.0.100/CurrDate 'not'
invoke CurrDate.pm from the anticipated directory of
/var/httpd/perl/MyApache?
Notice the Apache error log indicates that it is trying to access a file
under the directory /var/www/html/ rather than /var/www/perl/. This is done even though the perl.conf
file includes the Location directive which should redirect program
control to the respective perl module.
And, the startup script specs the parent directory where perl modules
can be found.

Incidentally, the intent of MyApache/CurrDate.pm is to test the existing
mod_perl environment for its ability to run handlers. (Better said, it is to test my ability
and the present set up. The system
is being initialized for the first time on this system. Another version of CurrDate.pm, in the
form of a script, was executable from a browser. So, Apache and Perl are likely set up
correctly.) Security of the files shouldn't be a problem.
The permissions of all respective
files have been set to assure they ought to be both readable and executable from
a browser.

Now when the browser is pointed to a different address, i.e.
//192.168.0.100/perl/CurrDate, then partial progress 'maybe' occurring
for
an Apache exception indicates:

[error] 13440: ModPerl::Registry: /var/www/perl/CurrDate.pm not found or
unable to stat

So it appears, with this later URL address, access to modperl is being
accomplished (!?). Granted, yet
another problem may exists; namely, the one generated by the ModPerl Registry
method. Hence, I may have two
problems to resolve rather than just the one.

An article (it is entitled Getting Your Feet Wet with mod_perl)
declares a handler with the syntax PerlResponseHandler ModPerl::Registry where
I have used a different syntax. It
was PerlHandler ModPerl::Registry::handler for the former would not work on
this system. The later was able to
successfully run a script. This
change was made to the directory /var/www/perl and not to the location called by
/CurrDate name space. This may not have relevance to the problem at
hand.

I understand Apache directives have a precedence. However, I have sequenced the order of
the directories in various ways without a resolution or apparent different
effect. Any
suggestions?

Thank you for your assistance.
#!/usr/bin/perl
#
# FileID: /perl/MyApache/currDate.pm
# Edition: 1600.08012003
# Editor: Steve Davis
# Install.: Powder Springs, GA
# Purpose: To display the current date
#
package MyApache::CurrDate;

use strict;
use warnings;

use Apache::RequestRec ();
use Apache::RequestIO ();
use Apache::Const -compile = qw(OK);

sub handler {

my ($SEC,$MIN,$HOUR,$MDAY,$MON,$YEAR,$WDAY,$YDAY,$ISDST) = localtime(time);
my $CURR_MONTH =
(Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov,Dec) [$MON + 1];
my

[mp2] input filter

2003-01-07 Thread Steve

**Hi again. I just noticed my last post regarding this was html formatted,
so I'm going to try again. Sorry about that everybody! **

I'm having some trouble configuring an input filter.. I'm using Apache
2.0.43, mod_perl 1.99_08-dev and perl 5.8.0.

In httpd.conf, I just did this inside a VirtualHost

PerlInputFilterHandler myApache::Filters::filter_in

My code looks something like this:

package myApache::Filters;
#here I loaded different modules etc..
sub filter_in : FilterConnectionHandler{
my ($filter, $bb, $mode, $block, $readbytes) = @_

my $rv =$filter-next-get_brigade($bb, $mode, $block, $readbytes);
return $rv unless $rv = APR::SUCCESS;

print STDERR INPUT FILTER\n;
my $c = $filter-c

return Apache::OK;
}


This is pretty much just taken from the mod_perl filter documenation, so I'm
pretty sure the code is OK.


My problem is this:

From the time I hit refresh in my browser to the time the content appears
takes a very long time. The request
completes eventually, it just takes forever. As soon as I take the filter
handler out of httpd.conf it works perfectly

Is this a configuration issue? Anyone have any ideas as to why this happens?

Thanks a lot

Steve

P.S Thanks for bearing with me through my posting debacles

Re: input filter

2003-01-06 Thread Steve

- Original Message -
From: Steves
To: [EMAIL PROTECTED]
Sent: Monday, January 06, 2003 7:10 PM
Subject: input filter

*Sorry if this has gotten sent twice*

Hello,

I'm having some trouble configuring an input filter.. I'm using Apache
2.0.43, mod_perl 1.99_08-dev and perl 5.8.0.

In httpd.conf, I just did this inside a VirtualHost

PerlInputFilterHandler myApache::Filters::filter_out

My code looks something like this:

package myApache::Filters;
#here I loaded different modules etc..
sub filter_in : FilterConnectionHandler{
my ($filter, $bb, $mode, $block, $readbytes) = @_

my $rv =$filter-next-get_brigade($bb, $mode, $block, $readbytes);
return $rv unless $rv = APR::SUCCESS;

print STDERR INPUT FILTER\n;
my $c = $filter-c

}

This is pretty much just taken from the mod_perl filter documenation, so I'm
pretty sure the code is OK.

My problem is, first and most obviously, the text INPUT FILTER gets
printed to STDERR twice per connection.
I'm not sure wether this is normal or not..

Secondly, from the time I hit refresh in my browser to the time the content
appears takes approximately one minute.. the request
completes eventually, it just takes a very long time. As soon as I take the
filter handler out of httpd.conf it works perfectly

Anyone know if this is a configuration issue or what? Thanks a lot for any
insights

Steve

SORRY!

The httpd.con configuration was a typo! It's really -

PerlInputFilterHandler myApache::Filters::filter_in

it IS configured correctly in my conf file, sorry about the confusion

Steve

Re: perl's system() w/ apache under win2k

2003-01-03 Thread Steve Hay

Terra Info wrote:


2) a probable answer anyhow-
[...] Check to see if the user you run apache under is allowed to 
interact with the desktop. It should be in the services CPL applet 
under the entry for that service. Check that and restart the service.

A related problem that I stumbled upon recently with a mod_perl program 
on WinNT is that the Win32::Shortcut module (used to create Windows 
shortcuts, a bit (but not much) like Unix links) doesn't work unless 
the Apache service is allowed to Interact with the Desktop.

- Steve

RE: mod_perl make failed: cannot find -lapr

.
[FAILED]  I have to comment out the invocation of mod_perl in order to
the web server to work.

A request for more help:

To continue with the football analogy which I started with, after
mod_perl was finally compiled, I thought I was headed for a touchdown.
Maybe, we have headed few yards toward the goal line.  But a little more
help is needed to head further towards making a score.  I'll start a new
thread for the sake this new problem.

Concluding comment:

For obvious reasons, I think Stan's comment about modify folks that the
last edition of mod_perl requires the respective compatible edition of
apache is an excellent idea.  This will avoid a lot of headaches.  The
sooner this comment is added to the mod_perl web page, the better.

Steve



Your help will be very much appreciated to resolve the following issue.
When attempting to make mod_perl.so, the make script 'almost' makes a
touchdown but fails before getting to the finishing line.  Now it is
time get some help from a coach.  Hopefully, with a little help, a
touchdown will soon follow.  Below, I present was appears to be the
problem, but someone else will have to direct me to the next set of
steps.

I've spend an extensive amount of time trying to resolve this myself and
it needs another set of eyes.  The news groups were reviewed
(repeatedly) for assistance, on-line docs, and what available books I
could find.

The environment is RH 8.0, Apache 2.0.43, Perl 5.8.0, mod_perl 1.99_07.
As best as I can tell, Apache, Perl, and mod_perl have been compiled
using the recommended configuration options listed in either Redhat's
instructions or mod_perl's on-line docs.  Get care has been taken to try
to dot every one and cross every 't' to my ability.

This problem 'may' have to do with an issue of a change of naming
conventions which were adapted by the apr apache group.  Confer with
Stas Bekman's post on Nov 26, 2002 with a title of Problems compiling
mod_perl 1.99_07 in RH 8.0.  He provides a cvs patch; but,
unfortunately, I'm not familiar with using that-as least-as of yet.
(Look's like I might have learn this package real soon.)  Are they any
intentions to update the mod_perl-1.99_07.tar.gz?  If my conclusion is
correct, then currently, and according to the on-line instructions, the
present tar.gz edition is not compatible to the latest edition of
apache. (2.0.43).  So, 'maybe' the cause of my make failure.  It appears
as if, only the cvs repository may be valid for compiling.  If my
analysis is correct, and a new edition of the respective non-cvs files
be acquired, then can non-CVS incremental files be obtained somehow?

I confess my ignorance and lack of familiarity with these packages so I
could be off.  

Thank you.   Steve

The environment is described below.

Apache has been configured with --prefix=/etc/httpd
--with-mpm=prefork.
Perl has been configured with -des -Dusethreads -Doptimize='-g'
-Dusedevel.
The perl Makefile.PL was flagged with MP_AP_PREFIX=/etc/httpd
MP_INST_APACHE2=1  MP_APXS=/etc/httpd/bin.  (I also, attempted to
configure the mod_perl makefile with the MP_APXS which generated the
same error message.)

The details follow below.

Here is excerpt from the screen dump from the make output.

make[1]
: Leaving directory `/usr/src/mod_perl/mod_perl-1.99_07/WrapXS'
make[1]
: Entering directory
`/usr/src/mod_perl/mod_perl-1.99_07/docs/api/mod_perl-2.0'
make[1]
: Leaving directory
`/usr/src/mod_perl/mod_perl-1.99_07/docs/api/mod_perl-2.0'
make[1]
: Entering directory `/usr/src/mod_perl/mod_perl-1.99_07/xs'
make[2]
: Entering directory `/usr/src/mod_perl/mod_perl-1.99_07/xs/APR'
make[3]
: Entering directory `/usr/src/mod_perl/mod_perl-1.99_07/xs/APR/APR'
rm -f 
../../../blib/arch/Apache2/auto/APR/APR.so
LD_RUN_PATH=/usr/lib cc  
-shared -L/usr/local/lib APR.o  -o ../../../blib/arch/Apache2-lapr
-laprutil
/usr/bin/ld

: cannot find -lapr
collect2

: ld returned 1 exit status
make[3]
: *** [../../../blib/arch/Apache2/auto/APR/APR.so] 
Error 1
make[3]
: Leaving directory `/usr/src/mod_perl/mod_perl-1.99_07/xs/APR/APR'
make[2]
: *** [subdirs] Error 2
make[2]
: Leaving directory `/usr/src/mod_perl/mod_perl-1.99_07/xs/APR'
make[1]
: *** [subdirs] Error 2
make[1]: Leaving directory `/usr/src/mod_perl/mod_perl-1.99_07/xs'
m

Here is a list of the files within /etc/httpd/lib.

-rw-r--r--  1 root root 6996 Dec 30 21:04
apr.exp
-rw-r--r--  1 root root 3481 Dec 30 21:04
aprutil.exp
-rwxr-xr-x  1 root root 21354 Dec 30 21:01 apxs
-rw-r--r--  1 root root 2685082 Dec 30 21:03 libapr-0.a
-rw-r--r--  1 root root 628 Dec 30 21:03
libapr-0.la
lrwxrwxrwx  1 root root 17 Dec 30 01:42
libapr-0.so - libapr-0.so.0.9.2
lrwxrwxrwx  1 root root 17 Dec 30 01:42
libapr-0.so.0 - libapr-0.so.0.9.2
-rwxr-xr-x  1 root root 1282063 Dec 30 01:42
libapr-0.so.0.9.2

mod_perl.c Not Compatible with Apache

Upon successfully compiling mod_perl 2.0, and modifying httpd.conf so
that it becomes invoked at the start of Apache 2.0.43, the following
error message is gernerated.  It is httpd failed. The error was:
Starting httpd: httpd: module mod_perl.c is not compatible with this
version of Apache.
Please contact the vendor for the correct version. [FAILED]

If you would like you, may refer to the previous thread named mod_perl
make failed: cannot find -lapr for a history of the root of this
problem-particularly the last post directly before this article.  This
also shows the detail environment and configuration for the server in
question.  Else, I would be glad more details to this post.  In brief,
let me say, the system consists of RH 8.0, apache 2.0.43, and current
CVS edition of mod_perl 2.0.  It has a date stamp of 1/1/03.

This is one problem which I don't know how to proceed with.  Is this
message saying the code in mod_perl's mod_perl.c is using an edition
of 'C' code that is incompatible with Apache 2.0?  Is the development
environment for which mod_perl 2.0 is being developed, by its creators,
using a 'C' compiler that is different than what is found on RH 8.0?
Does any one have an idea of how I might go about solving this problem?
Any advance given would be appreciated.  

Steve D

RE: mod_perl.c Not Compatible with Apache

Randy,

All of what I've done, in the form of compiling software, has been done
on the same computer and with the same release of the RH.  So, there is
nothing for which I'm doing to distinctly change which compiler is being
used between the compilations of the packages.

As best as I can recall, the answer is 'yes' to the last three questions
you asked.  1) Everything compiles successfully.  2) The edition of
mod_perl was obtained from cvs.apache.org while the Apache was from the
distribution source repository.  3) The various release numbers for the
packages where the most current; hence, 2.0.43 of Apache and 2.0 for
mod_perl.

Maybe there is some difference between the distribution and CVS versions
of Apache.  Perhaps, the next step will be to match packages via
obtaining CVS editions from both packages and see what happens then.
This shouldn't take to long.  I'll give it a shot and provide an update.


Let me also add, I'm grateful for your help.  Thank you.

Steve D

The following comments were provided from Randy Kobes:

I think in general the problem  mod_perl.c is not compatible with this
version of Apache.
means that mod_perl was compiled against a different set of Apache
sources than that used to build the server trying to load the mod_perl
module (assuming that the same compiler
is being used in building Perl, Apache, and mod_perl).

Just to clarify what came from where 

- are you using a modperl-2.0 cvs snapshot from
 http://cvs.apache.org/snapshots/modperl-2.0/?
- are you running Apache 2.0.43, compiled from the sources
  httpd-2.0.43.tar.gz from 
 http://httpd.apache.org/dist/httpd/?

If so, does modperl-2.0 compile against these apache 2.0 sources
successfully?

-- 
best regards,
randy

RE: mod_perl.c Not Compatible with Apache