Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Stas Bekman wrote: Steve Hay wrote: [...] Having a pointer to where the mod_perl.lib library was installed would be useful. I'm not sure calling it MODPERL_STATIC_LIB_LOCATION would be the best thing on Win32, as it's not a static library as such, but something could be come up with ... Well, if ModPerl::MM does the right thing, a developer will not even need to know where it is located. So probably leaving it as it's now is fine. The only misleading part is that MODPERL_LIB_LOCATION points to the build dir, so it should probably be renamed to reflect that. I'm not sure that's the *only* mis-leading part, but, as you say, if it all works then it shouldn't really matter too much. What other misleading parts are we talking about? I'm just getting confused with changes in Apache itself, I think. Apache 1 used to have lib, libexec and modules: lib stored the static .lib's, libexec stored the import libraries for various dll's, and modules stored the .so (aka .dll) files for Apache modules. But with Apache 2, I have only lib and modules. The latter still (rightly) contains just the .so files for Apache modules, so presumably all the static *and* import libraries are thrown together into lib now? Now, my mp2's Apache::BuildConfig contains this: 'MODPERL_AP_LIBDIR' = 'C:\\apache2/lib', 'MODPERL_AP_LIBEXECDIR' = 'C:\\apache2/modules', which I find confusing. The first line there is fine, but the second line seems wrong. One would think that MODPERL_AP_LIBEXECDIR specifies where Apache's libexec directory is, but there isn't one any more! Furthermore, it seems that the files that would have been in it are now in lib? So maybe MODPERL_AP_LIBEXECDIR should say C:\\apache2/lib (that's an ugly mess of back- and forward slashes too), and that should be used as the location to install mod_perl.lib into (since mod_perl.lib is one of these import library things). That would be wrong as things stand, though, because MODPERL_AP_LIBEXECDIR seems to be used as the location to install mod_perl.so, which should indeed be C:\\apache2/modules. Perhaps the simplest thing would be to rename MODPERL_AP_LIBEXECDIR to MODPERL_AP_MODDIR since it specifies where Apache's modules directory is and there isn't a libexec anymore? - Steve
[PATCH] Re: mp2 with perl-5.8.1 on Windows
Randy Kobes wrote:
On Fri, 12 Sep 2003, Steve Hay wrote:
Hi,
Has anybody else got mp2 (CVS) working with recent perl-5.8.1's on Windows?
I've got it building, but I can't start the Apache server at all. (It's
fine without the mod_perl bits in the httpd.conf file.)
See this thread on p5p for what I'm getting:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-09/msg00795.html
Cheers,
- Steve
I also found a problem, as below:
==
Perl_safesysmalloc(unsigned int 0x0010) line 70 + 21 bytes
: perl-5.8.1/util.c
modperl_hash_seed_init(apr_pool_t * 0x0026a7f0) line 44 + 7 bytes
: modperl-2.0/src/modules/perl/mod_perl.c
modperl_hook_pre_config(apr_pool_t * 0x0026a7f0,
apr_pool_t * 0x00848100, apr_pool_t * 0x0084a108) line 594 + 9 bytes
: modperl-2.0/src/modules/perl/mod_perl.c
ap_run_pre_config(apr_pool_t * 0x00401441, apr_pool_t * 0x0026a7f0,
apr_pool_t * 0x00848100) line 126 + 49 bytes
main(int 0x00401d82, const char * const * 0x0008) line 575 + 19 bytes
APACHE! mainCRTStartup + 227 bytes
==
which seems to be related to the safemalloc() call on line
44 of src/modules/perl/mod_perl.c. (by the way, I had to
comment out the fprintf() call at line 66 to get it to
compile, otherwise an error about my_perl being undeclared
was found).
I still haven't found out what the problem with the server crashing on
startup is, but the attached patch against CVS seems to fix the
fprintf() problem that you refer to.
I've no idea how advisable what I've done is, but without it I get:
=
cl -IC:/Temp/modperl-2.0/src/modules/perl
-IC:/Temp/modperl-2.0/xs -IC:\
apache2/include -IC:\apache2/include -nologo -Gf -W3 -Od -MD -Zi
-DDEBUGGING -DW
IN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT
-DPERL_IM
PLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -IC:\perl\lib\CORE
-DMOD_PERL -
DMP_COMPAT_1X -Od -MD -Zi -DDEBUGGING -c mod_perl.c
C:\perl\bin\perl.exe -M
ExtUtils::Command -e mv mod_perl.obj mod_perl.lo
mod_perl.c
mod_perl.c(66) : error C2065: 'my_perl' : undeclared identifier
mod_perl.c(66) : warning C4047: 'function' : 'struct interpreter *'
differs in l
evels of indirection from 'int '
mod_perl.c(66) : warning C4024: 'Perl_IStdIO_ptr' : different types for
formal a
nd actual parameter 1
mod_perl.c(66) : warning C4047: 'function' : 'struct interpreter *'
differs in l
evels of indirection from 'int '
mod_perl.c(66) : warning C4024: 'Perl_IStdIO_ptr' : different types for
formal a
nd actual parameter 1
NMAKE : fatal error U1077: 'cl' : return code '0x2'
Stop.
=
and with it, it all builds OK.
- Steve
PS. Randy: How do you that stacktrace output that you've posted? Is
that using MSVC++, or something else?
--- mod_perl.c.orig 2003-09-11 19:10:39.0 +0100
+++ mod_perl.c 2003-09-15 12:00:30.273019100 +0100
@@ -22,7 +22,7 @@
#endif
/* see modperl_hash_seed_set() */
-static void modperl_hash_seed_init(apr_pool_t *p)
+static void modperl_hash_seed_init(pTHX_ apr_pool_t *p)
{
#ifdef MP_NEED_HASH_SEED_FIXUP
char *s;
@@ -63,7 +63,8 @@
if (s) {
int i = atoi(s);
if (i == 1) {
-fprintf(stderr, \nmod_perl: using init hash seed: %UVuf\n,
+PerlIO_printf(PerlIO_stderr(),
+ \nmod_perl: using init hash seed: %UVuf\n,
MP_init_hash_seed);
}
}
@@ -587,10 +588,12 @@
int modperl_hook_pre_config(apr_pool_t *p, apr_pool_t *plog,
apr_pool_t *ptemp)
{
+dTHX;
+
/* we can't have PerlPreConfigHandler without first configuring mod_perl */
/* perl 5.8.1+ */
-modperl_hash_seed_init(p);
+modperl_hash_seed_init(aTHX_ p);
return OK;
}
Re: [PATCH] Re: mp2 with perl-5.8.1 on Windows
Randy Kobes wrote: On Mon, 15 Sep 2003, Steve Hay wrote: PS. Randy: How do you that stacktrace output that you've posted? Is that using MSVC++, or something else? Hi Steve, I'm using MSVC++ ... When a problem like this occurs, an offer is made to call up the VC++ debugger, where the trace is then done. In order to get a more useful trace (with symbol information), I compiled Perl using some patches to perl-5.8.x/win32/Makefile that ActiveState introduced (http://aspn.activestate.com/ASPN/Downloads/ActivePerl/Source). This patch enables debug symbols in release builds, and involves using '-Zi' in $(OPTIMIZE) and '-debug -opt:ref,icf' for $(LINK_DBG). With this, one gets .pdb files corresponding to compiled libraries, which hold the symbol information (I had to manually copy perl58.pdb [corresponding to perl58.dll] to C:\Perl\bin). The Apache/2.0.47 sources have this also enabled for the release build, by default, and building mod_perl as 'perl Makefile.PL ... MP_DEBUG=1' will enable them in mod_perl as well. Sorry, I should have made my question more specific. I've actually rebuilt Perl and Apache as full debug builds so I have all these .pdb files already. mod_perl gets them too because it inherits Perl's debug build mode. My question was where in the DevStudio GUI do you get at the stacktrace that you posted, or how do you get DevStudio to dump it out for you? All I can find is a Context drop-down (in the panel showing variables' values) from which I have to manually copy down the information (hence I only posted a list of functions!) It doesn't look like you've done that! - Steve
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Randy Kobes wrote: On Thu, 11 Sep 2003, Geoffrey Young wrote: The problem you described before with the missing symbols can be resolved by linking against the mod_perl.lib built when you build mod_perl.so. This can be done by adding in a LIBS attribute to WriteMakefile() in Makefile.PL with a value of ' -L/Path/to/mod_perl_lib -lmod_perl'. ah, right. thanks randy. examples of this can be found in Apache::WinBitHack, for example, the format of which should probably go in Apache::Dispatch (as well as just about all Apache:: modules to make sure they are Win32 compliant :) Here's a patch against the Apache-Dispatch Makefile.PL to allow it to build on Win32 Your patch does the trick for me, except that I had to rebuild mod_perl too. The problem is that my installed mod_perl setup (Apache in C:\apache, Perl in C:\perl5) didn't contain the mod_perl.lib required. The MODPERL_LIB entry in Apache::MyConfig said C:/Temp/mod_perl-1.28/src/modules/win32/Release, which is, of course, where it was when I was building mod_perl. I believe that mod_perl 2 now installs the mod_perl.lib somewhere to solve that kind of problem. Is there an option in the mod_perl 1 build process to thave that library installed, or could that be added to the next release? Anyway, Apache::Dispatch is now up and running for me. Thanks, Randy! - Steve
mp2 with perl-5.8.1 on Windows
Hi, Has anybody else got mp2 (CVS) working with recent perl-5.8.1's on Windows? I've got it building, but I can't start the Apache server at all. (It's fine without the mod_perl bits in the httpd.conf file.) See this thread on p5p for what I'm getting: http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-09/msg00795.html Cheers, - Steve
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Stas Bekman wrote: Randy Kobes wrote: On Fri, 12 Sep 2003, Steve Hay wrote: I believe that mod_perl 2 now installs the mod_perl.lib somewhere to solve that kind of problem. Is there an option in the mod_perl 1 build process to thave that library installed, or could that be added to the next release? That's a good suggestion - you're right that mod_perl 2 installs the mod_perl.lib under the Apache2/ tree, and it would make sense for mod_perl 1 to do the same, with Apache::MyConfig adjusted to reflect that. I'll look into putting together something to do that. Does it? According to Apache::Build, it should be installed under the apache tree's lib: Yes, in my Apache2 setup (the one that I can't get working with Perl 5.8.1...) I have mod_perl.lib in C:\Apache2\lib. I didn't change any of the installation locations. I'd assumed that's what Randy meant, actually - Apache2/lib being under the Apache2/ tree :-) Having said that, the BuildConfig.pm doesn't actually seem to refer to the location that the library has been installed into -- like mp1, it refers to the location in which it was built! I have: 'MODPERL_LIB_LOCATION' = 'C:/Temp/modperl-2.0/src/modules/perl/mod_perl.lib', in BuildConfig.pm. Wouldn't it be better for that to be 'C:/Apache2/lib/mod_perl.lib'? - Steve
Can't build Apache::Dispatch on Windows / Perl 5.8.0
Hi, I posted this problem the other day, deep inside a thread about something else, and didn't get any replies; maybe nobody spotted it? Does anybody have Apache::Dispatch working on Windows with Perl 5.8.0? Randy? I'm trying to build it on Windows XP (MSVC++ 6) with Perl 5.8.0 / Apache 1.3.27 / mod_perl 1.28, but I get these errors: [...] link -out:blib\arch\auto\Apache\Dispatch\Dispatch.dll -dll -nologo -node faultlib -release -libpath:C:\perl5\lib\CORE -machine:x86 Dispatch.obj C:\ perl5\lib\CORE\perl58.lib libeay32.lib oldnames.lib kernel32.lib user32.lib gdi 32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.li b netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib o dbccp32.lib msvcrt.lib -def:Dispatch.def Creating library blib\arch\auto\Apache\Dispatch\Dispatch.lib and object blib\ arch\auto\Apache\Dispatch\Dispatch.exp Dispatch.obj : error LNK2001: unresolved external symbol _perl_perl_merge_dir_co nfig Dispatch.obj : error LNK2001: unresolved external symbol _perl_cmd_perl_TAKE1 Dispatch.obj : error LNK2001: unresolved external symbol __imp__ap_register_clea [EMAIL PROTECTED] Dispatch.obj : error LNK2001: unresolved external symbol _perl_perl_cmd_cleanup Dispatch.obj : error LNK2001: unresolved external symbol __imp__ap_null_cleanup Dispatch.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] Dispatch.obj : error LNK2001: unresolved external symbol _perl_clear_symtab Dispatch.obj : error LNK2001: unresolved external symbol __imp__ap_remove_module @4 Dispatch.obj : error LNK2001: unresolved external symbol __imp__ap_find_linked_m [EMAIL PROTECTED] Dispatch.obj : error LNK2001: unresolved external symbol _perl_get_startup_pool Dispatch.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] blib\arch\auto\Apache\Dispatch\Dispatch.dll : fatal error LNK1120: 11 unresolved externals NMAKE : fatal error U1077: 'link' : return code '0x460' Stop. Any ideas? - Steve
Re: Help wanted with locations / configuration
Steve Hay wrote: Thomas Klausner wrote: Hi! On Mon, Sep 08, 2003 at 04:51:55PM +0100, Steve Hay wrote: The project is going to be written as a series of mod_perl handlers - one for the main home page, and others for various sub-components. Each handler is implemented by a separate module (all sub-classes of a common base class). I don't want to have to configure a separate Location for each sub-component. You might want to take a look at Apache::Dispatch, which does exactly this. Will do! I've grabbed it off CPAN and will take a good look at it. It does indeed look like exactly what I'm after. Does anybody have Apache::Dispatch working on Windows? I'm trying to build it on Windows XP (MSVC++ 6) with Perl 5.8.0 / Apache 1.3.27 / mod_perl 1.28, but I get these errors: [...] link -out:blib\arch\auto\Apache\Dispatch\Dispatch.dll -dll -nologo -node faultlib -release -libpath:C:\perl5\lib\CORE -machine:x86 Dispatch.obj C:\ perl5\lib\CORE\perl58.lib libeay32.lib oldnames.lib kernel32.lib user32.lib gdi 32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.li b netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib o dbccp32.lib msvcrt.lib -def:Dispatch.def Creating library blib\arch\auto\Apache\Dispatch\Dispatch.lib and object blib\ arch\auto\Apache\Dispatch\Dispatch.exp Dispatch.obj : error LNK2001: unresolved external symbol _perl_perl_merge_dir_co nfig Dispatch.obj : error LNK2001: unresolved external symbol _perl_cmd_perl_TAKE1 Dispatch.obj : error LNK2001: unresolved external symbol __imp__ap_register_clea [EMAIL PROTECTED] Dispatch.obj : error LNK2001: unresolved external symbol _perl_perl_cmd_cleanup Dispatch.obj : error LNK2001: unresolved external symbol __imp__ap_null_cleanup Dispatch.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] Dispatch.obj : error LNK2001: unresolved external symbol _perl_clear_symtab Dispatch.obj : error LNK2001: unresolved external symbol __imp__ap_remove_module @4 Dispatch.obj : error LNK2001: unresolved external symbol __imp__ap_find_linked_m [EMAIL PROTECTED] Dispatch.obj : error LNK2001: unresolved external symbol _perl_get_startup_pool Dispatch.obj : error LNK2001: unresolved external symbol [EMAIL PROTECTED] blib\arch\auto\Apache\Dispatch\Dispatch.dll : fatal error LNK1120: 11 unresolved externals NMAKE : fatal error U1077: 'link' : return code '0x460' Stop. Any ideas? - Steve
Re: Help wanted with locations / configuration
Marc Slagle wrote: On Mon, 2003-09-08 at 11:51, Steve Hay wrote: It also needs to have access to various static resources (images, stylesheets, JavaScript libraries etc.). Thus, I want to have something like this: /myproject [mp1] /myproject/component1 [mp1] /myproject/component2 [mp1] ... /myproject/images [static] /myproject/javascript [static] /myproject/stylesheets [static] You might want to look at having a translation handler. As in a PerlTransHandler, yes? We're doing something similar to this, where images and javascripts live under the same directory structure as the handler is managing. Instead of trying to configure this via that httpd.conf file, we chose to have a translation handler look at the incoming uri and determine whether the request is for a static file or for the code. Is there a performance penalty with this? You're using Perl code to inspect the URI, and then handing control back to the Apache core if it is a static file. I wanted to avoid requests for static files wasting time by going to a Perl handler only to be returned to the Apache core to serve the file, hence my LocationMatch override that catches requests for static files. Thanks for the code snippet, though - it looks pretty good to me aside from that concern. - Steve
Re: Help wanted with locations / configuration
Perrin Harkins wrote: On Mon, 2003-09-08 at 11:51, Steve Hay wrote: Thus, I want to have something like this: /myproject [mp1] /myproject/component1 [mp1] /myproject/component2 [mp1] ... /myproject/images [static] /myproject/javascript [static] /myproject/stylesheets [static] The question is: What is the best way to configure this? Others have already given good advice, They have, indeed. Thanks, everyone! but I would add that your URLs and your filesystem don't need to be tied tightly together. You could just alias the static files to somewhere else: [snip] Alternatively, you could use a Location setting for your dispatcher that has nothing to do with your files: Those were actually my very frist ideas, but I decided that I prefer to have all the URL's to begin with /myproject. I don't necessarily require that URL to be related to the filesystem structure, but I just want all the URL's (dynamic and static) to begin the same. - Steve
Re: Help wanted with locations / configuration
petersm wrote: Steve Hay [EMAIL PROTECTED] wrote Location /myproject SetHandler perl-script PerlHandler MyProject-dispatcher /Location LocationMatch ^/myproject/(images|javascript|stylesheets) SetHandler default-handler /LocationMatch Correct me if I'm wrong, but can't you just say Location /myproject Location /myproject AddHandler perl-script .cgi PerlHandler MyProject-dispatcher /Location using AddHandler instead of SetHandler. This will not override the default handler for things like images/stylesheets/static html. This way you don't need the LocationMatch ^/myproject/(images|javascript|stylesheets) ... tags. I prefer for reasons that I can't really explain to have the Perl handler locations having no extension - e.g. things like /myproject/component1 rather than /myproject/component1.cgi. I can't see how to achieve that with an AddHandler. (And even if I did get that working somehow, then the Perl handler would have to hand control back to the Apache core when it receives a request for /myproject/images.) Thanks for the idea, though. If I manage to overcome my inexplicable aversion to file extensions then it certainly looks like the simplest solution. - Steve
Help wanted with locations / configuration
Hi, I'm having trouble deciding what the best plan is for the arrangement of the components of a new project that I'm starting. The project is going to be written as a series of mod_perl handlers - one for the main home page, and others for various sub-components. Each handler is implemented by a separate module (all sub-classes of a common base class). I don't want to have to configure a separate Location for each sub-component. It also needs to have access to various static resources (images, stylesheets, JavaScript libraries etc.). Thus, I want to have something like this: /myproject [mp1] /myproject/component1 [mp1] /myproject/component2 [mp1] ... /myproject/images [static] /myproject/javascript [static] /myproject/stylesheets [static] The question is: What is the best way to configure this? So far I've come up with two options: OPTION 1. Specify a /myproject Location with dispatcher method as the mod_perl handler; then specify a LocationMatch for the images, javascript and stylesheets that overrides the /myproject Location: Location /myproject SetHandler perl-script PerlHandler MyProject-dispatcher /Location LocationMatch ^/myproject/(images|javascript|stylesheets) SetHandler default-handler /LocationMatch The dispatcher method there looks at the URI requested and either returns DECLINED (or 404?) if it doesn't recognise it, or else loads the appropriate MyProject sub-class and then runs the real content generation routine in that (i.e. a routine like I would have specified as the handler for that URI if I had configured a separate Location for each component). This seems to have a minor problem in practice -- if I request a directory, rather than a file, in one of the static locations (e.g. /myproject/images or /myproject/images/) then the dispatcher method gets called! The LocationMatch override only seems to work if I request a file (e.g. /myproject/images/piccy1.jpg). Thus, I need to put some extra code into the dispatcher to repeat the pattern match for the static locations, and change the handler to the default-handler and return DECLINED if it has received such a URI. OPTION 2. Specify a /myproject Location with a PerlFixupHandler that behaves very much like the dispatcher above, except that it actually sets the handler to PerlHandler and assigns the appropriate callback method (i.e. the content generation routine in the component sub-class) when it spots a recognised component URI; otherwise it just returns DECLINED, leaving the request to be handled by the default-handler: Location /myproject PerlFixupHandler MyProject-fixup /Location (Am I correct in thinking that I don't need to specify SetHandler: perl-script for a PerlFixupHandler? That's only for the main PerlHandler response handler, isn't it?) Does either of these options have any benefit over the other? Are there other better ways to do it? Thanks in advance, - Steve
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: [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
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: need your help to test mod_perl with perl-5.8.1-RC3
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
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
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
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
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
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()?
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()?
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()?
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()?
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()?
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
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
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
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
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
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: perl's system() w/ apache under win2k
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: Problem compiling mod_perl 1.27 on Windows
Randy Kobes wrote: On Mon, 16 Dec 2002, Steve Hay wrote: Is there some other way, for Win32, to achieve what the PERL_USELARGEFILES=0 hack tried to do? This seems hard to do without recompiling either the standard Apache sources (to enable large_files support) or else the standard ActivePerl 8xx sources (to disable large_files support). Sounds like recompiling Perl from the ActivePerl 804 sources with large_files support disabled is my best bet. Am I correct in thinking that all I need to do to achieve this is change uselargefiles='define' back to uselargefiles='undef' in win32/config.vc, or is there anything else that I need to fiddle with too? - Steve
Problem compiling mod_perl 1.27 on Windows
Hi, I'm having trouble compiling mod_perl 1.27 (with Apache 1.3.27 / Perl 5.8.0) on Windows (XP SP1 with MS VC++ 6.0 SP5). It builds fine with Perl 5.8.0 standard sources, but I'm just trying to upgrade my Perl to the slightly patched sources that ActivePerl Build 804 uses. I've built Perl from these new sources with the same build options that I used before for the standard source build (no threading, and Perl's malloc). (The output of Perl -V is at the bottom of this mail.) I run the following commands to build mod_perl: perl Makefile.PL APACHE_SRC=C:/apache INSTALL_DLL=C:/apache/modules EAPI nmake The first command runs fine, but the second has the following error: Apache.xs(1963) : error C2115: '=' : incompatible types The line referred to by this error is: statcache = r-finfo; I've no idea why this should be causing a problem with the new Perl. If I switch the Perl that I'm building against back to the standard 5.8.0 (by simply re-naming directories) and then re-run the nmake command above then mod_perl compiles and links with no errors. Can anyone shed any light on this? - Steve = 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=define 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 -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='__int64', lseeksize=8 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: USE_LARGE_FILES Built under MSWin32 Compiled at Dec 13 2002 08:42:43 @INC: C:/perl5/lib C:/perl5/site/lib .
Re: Problem compiling mod_perl 1.27 on Windows
Randy Kobes wrote:
On Mon, 16 Dec 2002, Steve Hay wrote:
I'm having trouble compiling mod_perl 1.27 (with Apache 1.3.27 / Perl
5.8.0) on Windows (XP SP1 with MS VC++ 6.0 SP5).
It builds fine with Perl 5.8.0 standard sources, but I'm just trying to
upgrade my Perl to the slightly patched sources that ActivePerl Build
804 uses. I've built Perl from these new sources with the same build
options that I used before for the standard source build (no threading,
and Perl's malloc). (The output of Perl -V is at the bottom of this
mail.)
[ .. ]
Characteristics of this binary (from libperl):
Compile-time options: USE_LARGE_FILES
I've found the same thing - I believe it's because of the
USE_LARGE_FILES support that ActivePerl 8xx has enabled, and this
runs into a conflict with the standard Win32 apache-1 which
doesn't have such support (in the above, statcache is from the
Perl side, and r-finfo is from Apache). This is still being
looked into ...
One possibility is to recompile Apache with large_file support,
but this is non-trivial. And since the bulk of Win32 development
on Apache is going into Apache-2, it may be hard to get an Apache
developer to look at this.
Looking at mod_perl (1.27)'s Makefile.PL I see that there is a
uselargefiles_check() routine that originally warned about conflicts,
but now (as of 1.27, according to the Changes file) automatically sets
PERL_USELARGEFILES=0 to try to avert disaster. But the only difference
that this seems to make is to stop Perl's $Config{ccflags} from being
appended to PERL_EXTRA_CFLAGS. However, my Perl (804)'s
$Config{ccflags} doesn't mention anything to do with large_files, so
it's hardly surprising that disaster is not averted (if this is indeed
the problem).
Is there some other way, for Win32, to achieve what the
PERL_USELARGEFILES=0 hack tried to do?
I also see that the warning that was originally output by
uselargefiles_check() suggested re-building Apache with large_files
support by simply specifying a couple of extra defines. I take it from
what you're saying that it isn't quite as trivial as that on Win32?
By the way, mod_perl-2 (for use with Apache2) compiles fine with
the ActivePerl sources.
I've been reluctant to use mod_perl 2 for anything more than testing
purposes yet because its current version number (1.99_07) doesn't fill
me with confidence that it's sufficiently stable. The mod_perl setup
that I'm trying to build is destined for a production environment, so
I'd rather stick to more tried and tested things for now.
I would be interested to hear how stable people think mod_perl 2
currently is on Win32.
- Steve
Shared variables, inner subs and our
Hi,
I was just tidying up an old mod_perl script which had some ugly "use
vars qw(...);" lines in it which I thought I'd replace with "our ...;".
I realise this isn't always a good idea since "our" is not intended as a
replacement for "use vars", but its often OK and I thought it would be
in my case.
I was only half right: The script still works fine, but emits warnings
which it previously didn't about "variable will not stay shared".
The mod_perl Guide (1.28) refers to such problems in section 3.5:
It gives as an example the following program:
use strict;
use warnings;
sub print_power_of_2 {
my $x = shift;
sub power_of_2 {
return $x ** 2;
}
my $result = power_of_2();
print "$x^2 = $result\n";
}
print_power_of_2(5);
print_power_of_2(6);
This prints:
Variable "$x" will not stay shared at ./nested.pl line 7.
5^2 = 25
6^2 = 25
The solution is to use a package-global $x which won't get deep-bound
into power_of_2():
use strict;
use warnings;
sub print_power_of_2 {
use vars qw($x);
$x = shift;
sub power_of_2 {
return $x ** 2;
}
my $result = power_of_2();
print "$x^2 = $result\n";
}
print_power_of_2(5);
print_power_of_2(6);
This prints:
5^2 = 25
6^2 = 36
However, if you change the ugly "use vars" to the
sexier-although-not-quite-the-same "our":
use strict;
use warnings;
sub print_power_of_2 {
our $x = shift;
sub power_of_2 {
return $x ** 2;
}
my $result = power_of_2();
print "$x^2 = $result\n";
}
print_power_of_2(5);
print_power_of_2(6);
then it prints:
Variable "$x" will not stay shared at ./nested.pl line 7.
5^2 = 25
6^2 = 36
!!!
In other words, we get a bizarre cross between the two: the warning
about $x not staying shared is emitted, but of course its nonsense (?)
because package-globals don't get deep-bound into subroutines anyway,
and the program actually works fine!
The eagle-eyed will have noticed that the above "use vars" solution is
not *exactly* as presented in the mod_perl Guide: the solution there
puts the "use vars" *outside" of the declaration of print_power_of_2(),
not *inside* as above. This, of course, makes no difference to "use
vars" which affects the package, not a lexical scope.
But it *does* make a big difference to "our", which applies to a lexical
scope, not a package: If we move the "our" *outside* of the declaration
of print_power_of_2():
use strict;
use warnings;
our $x;
sub print_power_of_2 {
$x = shift;
sub power_of_2 {
return $x ** 2;
}
my $result = power_of_2();
print "$x^2 = $result\n";
}
print_power_of_2(5);
print_power_of_2(6);
then the confusing warning goes away:
5^2 = 25
6^2 = 36
Why am I bringing this up?
(a) because I think the mod_perl Guide needs to mention the use of "our"
as well as "use vars" (they're only very briefly mentioned, regarding
something else, in section 10.6.5);
(b) because I can't actually do what I just did above in my mod_perl
script!
I run my mod_perl script under Apache::Registry, which (as we all know)
makes the script into a subroutine, and therefore any subroutines into
inner subroutines.
In the example above, print_power_of_2() is like my script, power_of_2()
is like a subroutine in my script, and the two calls to
print_power_of_2() are like my script being run twice.
Obviously I can't move the "our" declaration *outside* my script like I
did above (unless Apache::Registry did this for me when it does its
stuff with my script), so I'm stuck with the warning (or else "use
vars").
Is there some reason why the warning gets emitted with "our" inside
print_power_of_2()? Was I just lucky that this particular example
worked and I should really heed the warning, or is the warning actually
bogus?
Is there any way I can use "our" rather than "use vars" and not get
these warnings?
- Steve Hay
Re: Stop button (was: Re: General Question)
Bill Moseley wrote: At 02:02 PM 02/26/01 +, Steve Hay wrote: I have a script which I wish to run under either mod_perl or CGI which does little more than display content and I would like it to stop when the user presses Stop, but I can't get it working. You need to do different things under mod_perl and mod_cgi. Refer to the Guide for running under mod_perl -- you probably should check explicitly for an aborted connection as the guide shows. Oh dear. The program has to run on various different machines around the place, some of which run Apache/mod_perl and some of which run Microsoft IIS/CGI, so I really want one solution which works in both environments if at all possible. [This is all from my memory, so I hope I have the details correct] Under mod_cgi Apache will receive the SIGPIPE when it tries to print to the socket. Since your CGI script is running as a subprocess (that has been marked "kill_after_timeout", I believe), apache will first close the pipe from your CGI program, send it a SIGTERM, wait three seconds, then send a SIGKILL, and then reap. This all happens in alloc.c, IIRC. This is basically the same thing that happens when you have a timeout. So, you can catch SIGTERM and then have three seconds to clean up. You won't see a SIGPIPE unless you try to print in that three second gap. I'm fairly sure the program does print in any given three second gap -- I see the "x"s appearing in my browser window (since output is "unbuffered") at the rate of two or three per second, so I really should get the SIGPIPE. I've also tried adding in a similar handler to try and catch a SIGTERM and exit(), but that doesn't seem to work either. Has anybody else had any luck responding to "Stop" on NT? Cheers, Steve Hay
Re: Stop button (was: Re: General Question)
Hi,
Stas Bekman wrote:
Apache 1.3.6 and up -- STOP pressed:
the code keeps on running until it tries to read from or write to the
socket. the moment this happens, the script will stop the execution, and
run cleanup phase.
I think it's the same under mod_perl and mod_cgi. Am I right?
I have a script which I wish to run under either mod_perl or CGI which does
little more than display content and I would like it to stop when the user
presses Stop, but I can't get it working.
I've been trying to figure things out with the following test program:
---
use strict;
use warnings;
$SIG{PIPE} = \handler;
$| = 1;
print "Content-Type: text/plain\n\n";
for (;;) {
for (1 .. 100) { ; }
print "x\n";
}
sub handler {
# Unreliable signals on NT:-
$SIG{PIPE} = \handler;
exit;
}
---
(The pointless time-wasting loop just before each print() is so that I can
easily see whether the program actually has exited or not -- I'm running on NT
(groan!) and I can see in my "Task Manager" display that the Apache child
process is flat out 100% CPU while its running.)
I would expect that when the user presses Stop and the script next tries a
print() it'll get a SIGPIPE, call the handler(), and exit().
But it doesn't -- the Apache child process just carries on at 100% CPU.
It makes no difference whether I run it under mod_perl or mod_cgi (except that,
of course, I get a Perl process at 100% CPU instead of the Apache child), and it
also makes no difference if I take out the first "$SIG{PIPE} = \handler;" line
(and rely on mod_perl to handle the SIGPIPE for me as Stas described above)
and/or put the "PerlFixupHandler Apache::SIG" directive in my httpd.conf.
Can anybody help/explain?
I'm running Apache/1.3.17 and mod_perl/1.25 on Windows NT 4.
Cheers,
Steve Hay
Using Filter Module under mod_perl
Hi, I'm having trouble trying to use the Filter module under mod_perl. The attached script + module correctly outputs "Goodbye, world." under Apache/CGI, but says "Hello, world." under Apache/mod_perl (with Apache::Registry), i.e. the filter is not being applied. I looked into this once before, but got nowhere with it. Doug MacEachern had a *very* quick look last time and suggested maybe: "... the filter mechanism is tied into the perl_parse() and/or perl_run() functions, which are only called once by the perl (command line) binary, and only once by mod_perl. So it could be the case that Apache::Registry is simply too late in the game to use Perl filters." I e-mailed the module's author (Paul Marquess) recently. He is not familiar with the internals of mod_perl (neither am I), but he said: "If mod_perl calls perl_parse, I'm not sure why the filters aren't working. The filters hooks all live in yylex, which get called indirectly by perl_parse." Is there anyone familiar with both Filter and mod_perl who could shed any more light on what's going on here? Thanks, Steve Hay Hello2Goodbye.pm filtertest.pl
Win32: system() calls with STDOUT re-directed
I've finally solved a problem which I've had for a long time which may be of interest. I know some people looked at it for me at the time, including Randy Kobes. The problem was that the following script did not correctly execute it's system() call. The ip.txt file was never written and the status was set to 256. Running under CGI the file was written and the status was 0. (The problem never occurred if STDOUT from the ipconfig program is not re-directed to a file.) $| = 1; $pg = "Content-Type: text/plain\n\n"; $status = system "D:\\WINNT\\system32\\ipconfig.exe D:\\Temp\\ip.txt"; $pg .= "The system call exited with status $status.\n"; print $pg; I've found that since re-building everything with the inclusion of mod_ssl (2.6.5) the problem goes away! I kept everything else the same (Perl 5.6.0, Apache 1.3.12, mod_perl 1.24 on NT4 SP6). I wonder if this is anything to do with the EAPI (extended API) which mod_ssl patches the Apache core code with, since I don't actually need to *use* mod_ssl, just build with it - i.e. I don't even need to have a "LoadModule ssl_module modules/ApacheModuleSSL.dll" line in my httpd.conf file! It could also explain why other people were unable to re-produce my problem. Randy: I think you looked at this for me around the beginning of April and couldn't re-produce it. Do you think you had mod_ssl included in your build? Does this have any other implications for mod_perl??? Does mod_perl need the EAPI like mod_ssl does (at least on Win32)??? Steve Hay
Re: Problem compiling mod_perl 1.23 on Solaris 2.4
John D Groenveld wrote:
-Xa is a Sun WorkShop Compiler C 4.2 option,
-X[a|c|s|t]
Specifies the degree of conformance to the ANSI C stan-
dard. Specifies one of the following:
a (ANSI)
ANSI C plus KR C compatibility extensions, with
semantic changes required by ANSI C. Where KR C
and ANSI C specify different semantics for the
same construct, the compiler will issue warnings
about the conflict and use the ANSI C interpreta-
tion. This is the default compiler mode.
The machine I was building on was Solaris 2.4 with the Sun Compiler v3.0
in which the cc manpage says "-Xt" ('transition') is the default. I
also have a Solaris 2.6 machine with the Sun Compiler v4.0 which says,
like the snippet above, that "-Xa" is the default.
Steve Hay
Re: Problem compiling mod_perl 1.23 on Solaris 2.4
Steve Hay wrote: I'm having a problem compiling mod_perl 1.23 (with Apache 1.3.12 / Perl 5.6.0) as a DSO using APXS on Solaris 2.4. In case anyone is interested... I've solved my own problem (just as well, really). If I re-compile everything with the -Xa compiler flag then it all works out fine.
Compiling mod_perl on Windows NT
Hi, I've just been building Perl 5.6.0 / mod_perl 1.23 / Apache 1.3.12 on Windows NT and found something which may be of some use. The Apache installation does not seem to copy the headers and library files from the build directory into the install directory (which it DOES on Unix), so to build mod_perl you need to keep that Apache build build directory handy. I found that manually copying apache_1.3.12\src\include apache_1.3.12\src\os\win32\*.h apache_1.3.12\src\CoreR\ApacheCore.lib into the install directory and then pointing the DevStudio include/library paths at these locations in the install directory works fine, thus removing the need to keep the build directory floating about. This presumably means that I can now ditch the build directory and still be able to build mod_perl 1.24 when it comes using only my Apache install directory. - Steve Hay
Problem with CGI::Carp under mod_perl
I'm having problems using "CGI::Carp qw(fatalsToBrowser);" in modperl scripts. Below are three short scripts and their output under Apache/CGI and Apache/modperl. All three of them produce (more or less) useful output under Apache/CGI, but only the last one does under Apache/modperl. The first one calls die() itself. Under Apache/CGI the die() message appears in the web browser (albeit preceded by a spurious Content-Type line), but under Apache/modperl the message goes to the error.log and a bizarre message appears in the web browser consisting of some output from the script, followed by a "200 OK" HTTP header, followed by a message suggesting that all was not OK after all (all the same as if CGI::Carp was not being used). The second one has a syntax error. Under Apache/CGI a message about a compilation error appears in the web browser (but not the detail of the syntax error itself, which disappears completely - not even going to error.log!); under Apache/modperl an "Internal Server Error" message appears in the web browser (again just like CGI::Carp was not being used) and (curiously) the detail of the syntax error does now at least appear in error.log! The third one attempts a division by zero and correctly says so in the web browser under both Apache/CGI and Apache/modperl. Can anybody explain what's going on here??? The first script is closest to the problem I've really got. I'm using DBI/DBD::mysql and I want SQL syntax errors (which I keep making) to appear in the web browser instead of having to keep opening the error.log. Running under Apache/CGI I get useful messages like: Software error: DBD::mysql::st execute failed: You have an error in your SQL syntax near 'BINARY USER_NAME LIKE 'mk-%' LIMIT 10' at line 1 at d:/inetpub/cgi-bin/mysql.pl line 300. but under Apache/modperl I just get useless garbage like the error_die.pl below produces. I'm running Perl 5.005_03 / Apache 1.3.6 / mod_perl 1.22 on NT 4. error_die.pl use CGI::Carp qw(fatalsToBrowser); $| = 1; print "Content-Type: text/html\n\n"; print "I'm about to die() ...\n"; die "I'm dead.\n"; Apache/CGI: I'm about to die() ... Content-type: text/html Software error: I'm dead. For help, please send mail to the webmaster ([EMAIL PROTECTED]), giving this error message and the time and date of the error. Apache/modperl: I'm about to die() ... HTTP/1.1 200 OK Date: Tue, 18 Apr 2000 11:09:35 GMT Server: Apache/1.3.6 (Win32) mod_perl/1.22 Connection: close Content-Type: text/html OK The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, [EMAIL PROTECTED] and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. error_syntax.pl --- use CGI::Carp qw(fatalsToBrowser); $| = 1; print "Content-Type: text/html\n\n"; print "Syntax error at the end of this line ...\n" print "blah blah blah.\n"; Apache/CGI: Software error: Execution of d:/inetpub/cgi-bin/error_syntax.pl aborted due to compilation errors. For help, please send mail to the webmaster ([EMAIL PROTECTED]), giving this error message and the time and date of the error. Apache/modperl: Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, [EMAIL PROTECTED] and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. error_divide.pl --- use CGI::Carp qw(fatalsToBrowser); $| = 1; print "Content-Type: text/html\n\n"; print "I'm about to divide by zero ...\n"; my $x = 1 / 0; Apache/CGI: Software error: Illegal division by zero at d:/inetpub/cgi-bin/error_divide.pl line 5. For help, please send mail to the webmaster ([EMAIL PROTECTED]), giving this error message and the time and date of the error. Apache/modperl: Software error: Illegal division by zero at d:/inetpub/cgi-bin/error_divide.pl line 5. For help, please send mail to the webmaster ([EMAIL PROTECTED]), giving this error message and the time and date of the error.
Problem with CGI::Carp under mod_perl
Sorry! Here it is again in text/plain this time... (My mail client doesn't ask whether I want to send in text or HTML, hence the slip. Maybe *I* should get a new one!) --- I'm having problems using "CGI::Carp qw(fatalsToBrowser);" in modperl scripts. Below are three short scripts and their output under Apache/CGI and Apache/modperl. All three of them produce (more or less) useful output under Apache/CGI, but only the last one does under Apache/modperl. The first one calls die() itself. Under Apache/CGI the die() message appears in the web browser (albeit preceded by a spurious Content-Type line), but under Apache/modperl the message goes to the error.log and a bizarre message appears in the web browser consisting of some output from the script, followed by a "200 OK" HTTP header, followed by a message suggesting that all was not OK after all (all the same as if CGI::Carp was not being used). The second one has a syntax error. Under Apache/CGI a message about a compilation error appears in the web browser (but not the detail of the syntax error itself, which disappears completely - not even going to error.log!); under Apache/modperl an "Internal Server Error" message appears in the web browser (again just like CGI::Carp was not being used) and (curiously) the detail of the syntax error does now at least appear in error.log! The third one attempts a division by zero and correctly says so in the web browser under both Apache/CGI and Apache/modperl. Can anybody explain what's going on here??? The first script is closest to the problem I've really got. I'm using DBI/DBD::mysql and I want SQL syntax errors (which I keep making) to appear in the web browser instead of having to keep opening the error.log. Running under Apache/CGI I get useful messages like: Software error: DBD::mysql::st execute failed: You have an error in your SQL syntax near 'BINARY USER_NAME LIKE 'mk-%' LIMIT 10' at line 1 at d:/inetpub/cgi-bin/mysql.pl line 300. but under Apache/modperl I just get useless garbage like the error_die.pl below produces. I'm running Perl 5.005_03 / Apache 1.3.6 / mod_perl 1.22 on NT 4. error_die.pl use CGI::Carp qw(fatalsToBrowser); $| = 1; print "Content-Type: text/html\n\n"; print "I'm about to die() ...\n"; die "I'm dead.\n"; Apache/CGI: I'm about to die() ... Content-type: text/html Software error: I'm dead. For help, please send mail to the webmaster ([EMAIL PROTECTED]), giving this error message and the time and date of the error. Apache/modperl: I'm about to die() ... HTTP/1.1 200 OK Date: Tue, 18 Apr 2000 11:09:35 GMT Server: Apache/1.3.6 (Win32) mod_perl/1.22 Connection: close Content-Type: text/html OK The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, [EMAIL PROTECTED] and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. error_syntax.pl --- use CGI::Carp qw(fatalsToBrowser); $| = 1; print "Content-Type: text/html\n\n"; print "Syntax error at the end of this line ...\n" print "blah blah blah.\n"; Apache/CGI: Software error: Execution of d:/inetpub/cgi-bin/error_syntax.pl aborted due to compilation errors. For help, please send mail to the webmaster ([EMAIL PROTECTED]), giving this error message and the time and date of the error. Apache/modperl: Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, [EMAIL PROTECTED] and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. error_divide.pl --- use CGI::Carp qw(fatalsToBrowser); $| = 1; print "Content-Type: text/html\n\n"; print "I'm about to divide by zero ...\n"; my $x = 1 / 0; Apache/CGI: Software error: Illegal division by zero at d:/inetpub/cgi-bin/error_divide.pl line 5. For help, please send mail to the webmaster ([EMAIL PROTECTED]), giving this error message and the time and date of the error. Apache/modperl: Software error: Illegal division by zero at d:/inetpub/cgi-bin/error_divide.pl line 5. For help, please send mail to the webmaster ([EMAIL PROTECTED]), giving this error message and the time and date of the error.
Re: [OT] mysql-modules for Win32 platform
Erich Markert wrote:
I've been trying to get the msql-mysql-modules compiled and installed on
my Win98 machine for a couple weeks without much luck.
I managed to get these working on NT4 with both 5.005_03 and 5.6.0 (both
built myself from the standard distribution, not the ActiveState build)
after a bit of hacking...
I tried using the latest version of perl 5.6 from active state but ran
into nothing but problems. Basically running perl Makefile.PL for
Data::ShowTable (a required module) failed because the version of perl
couldn't be determined - even after reinstalling.
I also had trouble with this when I had mSQL installed. It said "Unable to
find a perl 5" and then proceeded to name the files it was looking for
(including perl.exe!) and the directories where it was looking (including
D:\perl5\bin, which is where it was!). To my surprise, I found that
uninstalling mSQL and then trying to build Data::ShowTable again worked
fine! Weird. Anyway, I've now ditched mSQL in favour of the much better
MySQL which doesn't suffer this problem.
I don't know if this is the same problem you had -- you might have a
different problem because you're using the ActiveState build? I never had
much luck building any CPAN modules with that, which is why I never use
it...
I do still get 17/17 tests failed when running "nmake test" (!!!), but its
enough to stop msql-mysql-modules complaining that a pre-requisite is
missing.
I finally reverted back the a previous version of perl (Gurusamy
Sarathy's version 5.004_02) and was able to get Data::ShowTable and DBI
installed but now when I run perl Makefile.PL for Msql-Mysql-modules I
receive these errors:
Note (probably harmless): No library found for 'm.lib'
I got a similar message regarding "-lm" which I just ignored (!!!... well,
it said it was probably harmless :-)
I also found that I had to hack the Makefile generated by "perl Makefile.PL"
to change the two lines which say:
-e ppp '...' '...' '...'
to:
-e "ppp('...', '...', '...')"
and I hacked the Makefile in the mysql sub-directory to change:
OTHERLDFLAGS = -LD:\mysql/lib/opt
to:
OTHERLDFLAGS = -LIBPATH:D:\mysql/lib/opt
None of this was necessary on my Solaris 2.6 box, however, where everything
went like a dream...
- Steve Hay
Problem Compiling with Perl 5.6.0
Since I had no reply to my previous problem (re-directing STDOUT in system() calls), I thought I would try using Perl 5.6.0 instead of 5.005_03 (probably a good idea anyway) to see if that helped. Unfortunately, now I can't get (the Apache side of) mod_perl to compile. I'm using MSVC++ 6.0 on Windows NT 4. Perl 5.6.0 and Apache 1.3.12 compiled fine, as does the Perl side of mod_perl 1.22, but when I go into Dev Studio to compile the Apache side I get the following output for each file: D:\Temp\apache_1.3.12\src\include\../os/win32/os.h(87) : warning C4005: 'crypt' : macro redefinition D:\perl5\lib\CORE\win32iop.h(301) : see previous definition of 'crypt' D:\Temp\apache_1.3.12\src\include\../os/win32/os.h(109) : warning C4142: benign redefinition of type D:\Temp\apache_1.3.12\src\include\../os/win32/os.h(110) : warning C4142: benign redefinition of type D:\Temp\apache_1.3.12\src\include\../os/win32/os.h(112) : error C2371: 'mode_t' : redefinition; different basic types D:\perl5\lib\CORE\win32.h(197) : see declaration of 'mode_t' D:\Temp\apache_1.3.12\src\include\../os/win32/os.h(146) : warning C4005: 'sleep' : macro redefinition D:\perl5\lib\CORE\win32iop.h(279) : see previous definition of 'sleep' D:\Program Files\Microsoft Visual Studio\VC98\Include\stddef.h(78) : warning C4005: 'errno' : macro redefinition D:\perl5\lib\CORE\win32iop.h(188) : see previous definition of 'errno' D:\Temp\apache_1.3.12\src\include\../os/win32/os.h(165) : warning C4005: 'stat' : macro redefinition D:\perl5\lib\CORE\win32iop.h(223) : see previous definition of 'stat' D:\Temp\apache_1.3.12\src\include\../os/win32/readdir.h(34) : error C2373: 'win32_opendir' : redefinition; different type modifiers D:\perl5\lib\CORE\win32iop.h(116) : see declaration of 'win32_opendir' D:\Temp\apache_1.3.12\src\include\../os/win32/readdir.h(35) : error C2373: 'win32_readdir' : redefinition; different type modifiers D:\perl5\lib\CORE\win32iop.h(117) : see declaration of 'win32_readdir' D:\Temp\apache_1.3.12\src\include\../os/win32/readdir.h(36) : error C2373: 'win32_closedir' : redefinition; different type modifiers D:\perl5\lib\CORE\win32iop.h(121) : see declaration of 'win32_closedir' Any ideas, anyone? Has anyone else got 5.6.0 / 1.3.12 / 1.22 going on NT 4? Steve Hay
Re: Problem Compiling with Perl 5.6.0
"G.W. Haywood" wrote: Come to think of it, NT probably wasn't the best idea you ever had either. I agree, but we're selling a web application and most of our customers want it on NT. Unfortunately, now I can't get (the Apache side of) mod_perl to compile. You aren't alone. You really are on the bleeding edge with that lot. My advice would be ro try Linux, and stick with Perl 5.005_03 and mod_perl 1.21/Apache 1.3.11 (or .12) for a few weeks. Well, I got mod_perl 1.22 going on NT with Perl 5.005_03 / Apache 1.3.12 (apart from the problem with system() calls...) after two quick hacks (one to lib\Apache\src.pm and one to src\modules\perl\Util.xs) so it just seems a shame I can't get it to go with Perl 5.6.0. I just wondered if anyone out there new of any more hacks to help...
Re: Problem Compiling with Perl 5.6.0
Thanks for this! I tried it with the latest mod_perl cvs: mine now compiles perfectly too (_never_ seen that before!!!), and there's now only 1 unresolved external symbol instead of 7. Looks like it could be nearly there - I'll try another one some time. I look forward to mod_perl 1.23 ... Steve Hay Randy Kobes wrote: On Thu, 30 Mar 2000, Steve Hay wrote: Has anyone else got 5.6.0 / 1.3.12 / 1.22 going on NT 4? Hi, There's a couple things you can do - - add the flag /D "WIN32IOP_H" - this handles the win32_opendir and similar errors. - for the mode_t error, in apache/src/os/win32/os.h, change the typedef of mode_t from 'int' to 'unsigned short', so as to agree with the mode_t typedef of perl in perl/lib/core/win32.h. In the same apache os.h file, if you change the typedef of uid_t and gid_t from 'int' to 'long', again so as to agree with Perl's typedefs, then the compilation, at least for me, proceeeds without warnings. Unfortunately, there's some problems in the linking phase - some symbols that were present in perl.lib of 5.005_03 have been removed from perl56.lib of 5.6.0. Doug has worked on this - you may want to get the latest mod_perl cvs snapshot from http://perl.apache.org/ and try that.
Problem re-directing STDOUT in system() calls
Hi, I've had this problem before, but never got to the bottom of it. I'm cursed with a situation in which I need to run some .exe file from a (mod)perl script. The program concerned is a console application so it just writes its output on STDOUT. I need to re-direct that output to a temporary file, and then read the file in to process in the perl script. Sounds simple enough, and it works fine running Apache without mod_perl. But as soon as I put mod_perl into the equation I find that I can't re-direct STDOUT in the system() call. The following script illustrates the problem: print "Content-Type: text/html\n\n"; $status = system "D:\\WINNT\\system32\\ipconfig.exe D:\\Temp\\ip.txt"; print "The system() call exited with status $status.\n"; Without mod_perl this works fine: "ip.txt" is created and $status is 0. But with mod_perl "ip.txt" is not created, $status is 256 and the following line appears in error.log: The handle could not be opened during redirection of handle 1. Can anyone help? My setup is as follows: - NT 4 Workstation, Service Pack 6 - Perl 5.005_03 built with VC++ 6 and the Makefile options: CFG = Optimize USE_PERLCRT PERL_MALLOC - Apache 1.3.12 built with VC++ 6 - mod_perl 1.22 built with VC++ 6 - D: is a local disk which I have full access to I've found that the problem goes away if I downgrade to Apache 1.3.6 and keep everything else the same! Steve Hay
Re: Problem re-directing STDOUT in system() calls
"Andrei A. Voropaev" wrote: See the guide. Under modperl the output from system will not go to the user unless your perl was compiled with sfio. The reason for that I guess is that under modperl STDOUT is tied to a package, while system commands expect file descriptor. The easiest way to overcome it is to use `` (backtics) and capture all output into variable and then print it out. Andrei The guide actually says: 3.5.5 Output from system calls Output of system(), exec(), and open(PIPE,"|program") calls will not be sent to the browser unless your Perl was configured with sfio. which is fair enough, but does it explain the problem I've got? It DOES explain why the following script prints the output of IPCONFIG in the browser when running under Apache and doesn't when running under Apache + mod_perl: $| = 1; print "Content-Type: text/plain\n\n"; $status = system "D:\\WINNT\\system32\\ipconfig.exe"; print "The system() call exited with status $status.\n"; but that isn't my problem. How does it explain why the following works under Apache 1.3.6 + mod_perl and not under Apache 1.3.12 + mod_perl: print "Content-Type: text/plain\n\n"; $status = system "D:\\WINNT\\system32\\ipconfig.exe D:\\Temp\\ip.txt"; print "The system() call exited with status $status.\n"; ? I'm not trying to get the output of the system() call into the browser - I want to re-direct it to a file - and the difference between the one which works and the one which doesn't work is not mod_perl: it's the Apache version! Am I also correct in thinking that configuring Perl with sfio is only an option on Unix (which, BTW, doesn't have my problem anyway!)? Help! Steve Hay
