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
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
[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 -I"C:\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: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Stas Bekman wrote: Randy Kobes wrote: On Fri, 12 Sep 2003, Stas Bekman wrote: Steve Hay wrote: 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 :-) what is mod_perl.lib? a static library? (I guess an equivalent of mod_perl.lo on unix). We don't install it on unix yet, but I think that for consistency it should go to the same place where mod_perl.so is installed to. Which is under the Apache tree. This mod_perl.lib (on Win32) isn't a true static library, containing all the symbol definitions; from what I understand, it just contains the minimal information on symbols needed to allow the application it's being linked with to find the symbols in the dynamic library (in this case, mod_perl.so). I put it under Apache2/lib/ because that's where the Apache2 libs (eg, apr.lib, libapr.lib, mod_dav.lib) are placed. The dynamic libraries are placed either under Apache2/modules/, if it's a module (eg, mod_dav.so), or under Apache2/bin/, such as libapr.dll. Ah, so it's all cool. I have confused Apache2/ with perl's lib sub-directory. 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'? Nope, it uses this attribute as a source dir in cp from to: $install .= <<'EOI'; # install mod_perl.lib @$(MKPATH) $(MODPERL_AP_LIBDIR) $(MODPERL_TEST_F) $(MODPERL_LIB_LOCATION) && \ $(MODPERL_CP) $(MODPERL_LIB_LOCATION) $(MODPERL_AP_LIBDIR) EOI And as you can see it should install the static lib under $(MODPERL_AP_LIBDIR) (which is under the apache tree) purhaps it should be fixed to have a more intuitive name then (s/MODPERL_LIB_LOCATION/MODPERL_LIB_SOURCE_LOCATION/?) or BUILD_LOCATION I'd suggest an even more intuitive: MODPERL_STATIC_LIB_BUILD_LOCATION, since it's a static lib. Purhaps adding a new var MODPERL_STATIC_LIB_LOCATION pointing to where the static lib was installed to will be useful. 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. The main thing is to get mod_perl.lib installed in the first place under mp1. - 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
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
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
Re: Can't build Apache::Dispatch on Windows / Perl 5.8.0
Thomas Klausner wrote: Hi! On Thu, Sep 11, 2003 at 08:33:31AM +0100, Steve Hay wrote: 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? Randy posted this some time ago: I just made one up, which you can install as C:\> ppm install http://theoryx5.uwinnipeg.ca/ppmpackages/Apache-Dispatch.ppd Maybe this works for you? Sadly, no - that URL is now a 404. The directory there still exists, but there's no Apache-Dispatch.ppd in it. I would rather be able to build the module myself anyway, rather than using a PPM package. BTW, do other people have it working under Perl 5.8.0 on other platforms? I'm not sure if this problem is Windows-related or 5.8.0-related. - 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
petersm wrote: Steve Hay <[EMAIL PROTECTED]> wrote SetHandler perl-script PerlHandler MyProject->dispatcher SetHandler default-handler Correct me if I'm wrong, but can't you just say> AddHandler perl-script .cgi PerlHandler MyProject->dispatcher 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 ... 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
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
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
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. I'm using something like this with Apache::Dispatch PerlModule Apache::Dispatch DispatchUpperCase On # this is /not/ in Apache::Dispatch, # only in my patched version DispatchPrefix Oe1 DispatchExtras Error SetHandler perl-script PerlHandler Apache::Dispatch SetHandler default SetHandler default This is working as expected, i.e. request for /css/foo.css or /img/bar.png are not handled by Apache::Dispatch What about requests for /css or /img ? Are they handled by Apache::Dispatch? The problem I found with my LocationMatch override is that requests for files were caught, but requests for directories slipped through to the Perl handler. - 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: SetHandler perl-script PerlHandler MyProject->dispatcher SetHandler default-handler 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: PerlFixupHandler MyProject->fixup (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: 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: [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.47>nmake /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: 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[Apache should hopefully crash...]; print plural('bottle', $_) . " of beer on the wall, " . plural('bottle', $_) . " of beer, " . "Take one down and pass it around, " . plural('bottle', $_ - 1) . " of beer on the wall.\n" foreach (reverse (1 .. 99)); print qq[]; } #--- 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: [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 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 = ''; my $footer = ''; my $centre = '.' x ($size - length($header) - length($footer)); my $t_text = $header . $centre . $footer; return \$t_text; }
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: 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 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: 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 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: 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
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
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
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[ -I"C:/apache/include" -I"C:/apache/include/../os/win32" -I"C:/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
Re: need your help to test mod_perl with perl-5.8.1-RC3
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). Steve # This Makefile is for the libapreq extension to perl. # # It was generated automatically by MakeMaker version # 6.12 (Revision: 1.124) from the contents of # Makefile.PL. Don't edit this file, edit Makefile.PL instead. # # ANY CHANGES MADE HERE WILL BE LOST! # # MakeMaker ARGV: () # # MakeMaker Parameters: # INC => q[ -I"C:/apache/include" -I"C:/apache/include/../os/win32" -I"C:/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] # --- MakeMaker post_initialize section: # --- MakeMaker const_config section: # These definitions are from config.sh (via C:/perl5/lib/Config.pm) # They may have been overridden via Makefile.PL or on the command line AR = lib CC = cl CCCDLFLAGS = CCDLFLAGS = DLEXT = dll DLSRC = dl_win32.xs LD = link LDDLFLAGS = -dll -nologo -nodefaultlib -release -libpath:"C:\perl5\lib\CORE" -machine:x86 LDFLAGS = -nologo -nodefaultlib -release -libpath:"C:\perl5\lib\CORE" -machine:x86 LIBC = msvcrt.lib LIB_EXT = .lib OBJ_EXT = .obj OSNAME = MSWin32 OSVERS = 4.0 RANLIB = rem SITELIBEXP = C:\perl5\site\lib SITEARCHEXP = C:\perl5\site\lib SO = dll EXE_EXT = .exe FULL_AR = VENDORARCHEXP = VENDORLIBEXP = # --- MakeMaker constants section: AR_STATIC_ARGS = cr DIRFILESEP = ^\ NAME = libapreq NAME_SYM = libapreq VERSION = 1.2 VERSION_MACRO = VERSION VERSION_SYM = 1_2 DEFINE_VERSION = -D$(VERSION_MACRO)=\"$(VERSION)\" XS_VERSION = 1.2 XS_VERSION_MACRO = XS_VERSION XS_DEFINE_VERSION = -D$(XS_VERSION_MACRO)=\"$(XS_VERSION)\" INST_ARCHLIB = ..\blib\arch INST_SCRIPT = ..\blib\script INST_BIN = ..\blib\bin INST_LIB = ..\blib\lib INST_MAN1DIR = ..\blib\man1 INST_MAN3DIR = ..\blib\man3 MAN1EXT = 1 MAN3EXT = 3 INSTALLDIRS = site DESTDIR = PREFIX = PERLPREFIX = C:\perl5 SITEPREFIX = C:\perl5\site VENDORPREFIX = INSTALLPRIVLIB = $(PERLPREFIX)\lib DESTINSTALLPRIVLIB = $(DESTDIR)$(INSTALLPRIVLIB) INSTALLSITELIB = $(SITEPREFIX)\lib DESTINSTALLSITELIB = $(DESTDIR)$(INSTALLSITELIB) INSTALLVENDORLIB = DESTINSTALLVENDORLIB = $(DESTDIR)$(INSTALLVENDORLIB) INSTALLARCHLIB = $(PERLPREFIX)\lib DESTINSTALLARCHLIB = $(DESTDIR)$(INSTALLARCHLIB) INSTALLSITEARCH = $(SITEPREFIX)\lib DESTINSTALLSITEARCH = $(DESTDIR)$(INSTALLSITEARCH) INSTALLVENDORARCH = DESTINSTALLVENDORARCH = $(DESTDIR)$(INSTALLVENDORARCH) INSTALLBIN = $(PERLPREFIX)\bin DESTINSTALLBIN = $(DESTDIR)$(INSTALLBIN) INSTALLSITEBIN = C:\perl5\bin DESTINSTALLSITEBIN = $(DESTDIR)$(INSTALLSITEBIN) INSTALLVENDORBIN = DESTINSTALLVENDORBIN = $(DESTDIR)$(INSTALLVENDORBIN) INSTALLSCRIPT = $(PERLPREFIX)\bin DESTINSTALLSCRIPT = $(DESTDIR)$(INSTALLSCRIPT) INSTALLMAN1DIR = $(PERLPREFIX)\man\man1 DESTINSTALLMAN1DIR = $(DESTDIR)$(INSTALLMAN1DIR) INSTALLSITEMAN1DIR = $(SITEPREFIX)\man\man1 DESTINSTALLSITEMAN1DIR = $(DESTDIR)$(INSTALLSITEMAN1DIR) INSTALLVENDORMAN1DIR = DESTINSTALLVENDORMAN1DIR = $(DESTDIR)$(INSTALLVENDORMAN1DIR) INSTALLMAN3DIR = $(PERLPREFIX)\man\man3 DESTINSTALLMAN3DIR = $(DESTDIR)$(INSTALLMAN3DIR) INSTALLSITEMAN3DIR = $(SITEPREFIX)\man\man3 DESTINSTALLSITEMAN3DIR = $(DESTDIR)$(INSTALLSITEMAN3DIR) INSTALLVENDORMAN3DIR = DESTINSTALLVENDORMAN3DIR = $(DESTDIR)$(INSTALLVENDORMAN3DIR) PERL_LIB = C:\perl5\lib PERL_ARCHLIB = C:\perl5\lib LIBPERL_A = libpe
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: 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: 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-modperl&m=105912130001046&w=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: 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-modperl&m=105912130001046&w=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: 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
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-modperl&m=105912130001046&w=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: 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()
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
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 prog
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 # $str is stored in Perl's internal UTF-8 format. my $str = Encode::decode('iso-8859-1', 'Zurück'); print "$str\n"; print < 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 Philippe, Philippe M. Chiasson wrote: On Wed, 2003-06-25 at 00:12, Steve Hay wrote: Philippe M. Chiasson wrote: [...] 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-dev&m=105595499417788&w=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. Here is what I think I am going to do in light of all this and a high level of cafeeine... Take Apache::Reload from mp2 as-is (it's 0.9), and mod_perl1-ify it. Dump it in mod_perl 1 Change it's version number to 0.8_1 so CPAN won't pick it up. Release 1.28 (eventually...) Then work on the added functionnality for Apache::Reload and solve all other issues of dependencies on B, ModPerl::Util::symbol_undef_code, etc. Good idea! We've had so many ideas flying around about how to implement the new "UndefOnReload" feature and where to put the code that I'd completely forgotten that there is an existing module that already works (without that feature)! Getting that into mp1 as a first step is an excellent move. I don't want this issue to slow down the long-awaited release of 1.28. But at the same time , StatINC is quite old and users of mp1 should be 'motivated' to upgrade to Apache::Reload, so it makes sense to go in mp1 as well. Maybe for 1.29 we could even talk about deprecating/removing Apache::StatINC alltogether, for example. I expect there would be some objections to removing Apache::StatINC altogether (at least for while yet). Deprecating it is certainly a good idea once the "UndefOnReload" option is added to Apache::Reload; until then, some may actually prefer Apache::StatINC. 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: 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-dev&m=105595499417788&w=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: [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: [RELEASE CANDIDATE] Apache::Test 1.03-dev
Stas Bekman wrote: I've uploaded 1.03's release candidate. If nobody finds any faults, I'll upload it tomorrow on CPAN. (libapreq needs to rely on 1.03 fixes to release its 1.2's version). Please try it out: http://www.apache.org/~stas/Apache-Test-1.03-dev.tar.gz Tests OK for me - Windows XP / Perl 5.8.0 / Apache 1.3.27 / mod_perl 1.27
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
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
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 .
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 +0000, 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 K&R C compatibility extensions, with >semantic changes required by ANSI C. Where K&R 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.
Problem compiling mod_perl 1.23 on Solaris 2.4
Hi, 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. This worked fine using Apache 1.3.6 / Perl 5.005_03 / mod_perl 1.22. Can anybody help? I built the Perl with "-Uusemymalloc" which I had found was necessary under the previous setup. Here's the output:- radsun2-4% perl Makefile.PL USE_APXS=1 WITH_APXS=/usr/local/apache/bin/apxs EVERYTHING=1 Will configure via APXS (apxs=/usr/local/apache/bin/apxs) PerlDispatchHandler.enabled PerlChildInitHandlerenabled PerlChildExitHandlerenabled PerlPostReadRequestHandler..enabled PerlTransHandlerenabled PerlHeaderParserHandler.enabled PerlAccessHandler...enabled PerlAuthenHandler...enabled PerlAuthzHandlerenabled PerlTypeHandler.enabled PerlFixupHandlerenabled PerlHandler.enabled PerlLogHandler..enabled PerlInitHandler.enabled PerlCleanupHandler..enabled PerlRestartHandler..enabled PerlStackedHandlers.enabled PerlMethodHandlers..enabled PerlDirectiveHandlers...enabled PerlTableApienabled PerlLogApi..enabled PerlUriApi..enabled PerlUtilApi.enabled PerlFileApi.enabled PerlConnectionApi...enabled PerlServerApi...enabled PerlSectionsenabled PerlSSI.enabled Will run tests as User: 'radan' Group: 'usr' Configuring mod_perl for building via APXS + Creating a local mod_perl source tree + Setting up mod_perl build environment (Makefile) + id: mod_perl/1.23 + id: Perl/v5.6.0 (solaris) [perl] Now please type 'make' to build libperl.so Checking CGI.pm VERSION..ok Checking for LWP::UserAgent..ok Checking for HTML::HeadParserok Checking if your kit is complete... Looks good Writing Makefile for Apache Writing Makefile for Apache::Connection Writing Makefile for Apache::Constants Writing Makefile for Apache::File Writing Makefile for Apache::Leak Writing Makefile for Apache::Log Writing Makefile for Apache::ModuleConfig Writing Makefile for Apache::PerlRunXS Writing Makefile for Apache::Server Writing Makefile for Apache::Symbol Writing Makefile for Apache::Table Writing Makefile for Apache::URI Writing Makefile for Apache::Util Writing Makefile for mod_perl radsun2-4% make (cd ./apaci && make) cc -KPIC -O -I/usr/local/lib/perl5/5.6.0/sun4-solaris/CORE -DMOD_PERL_VERSION=\"1.23\" -DMOD_PERL_STRING_VERSION=\"mod_perl/1.23\" -I/usr/local/apache/include -DMOD_PERL -DSOLARIS2=240 -DUSE_HSREGEX -DUSE_EXPAT -I../lib/expat-lite -c mod_perl.c && mv mod_perl.o mod_perl.lo "/usr/local/lib/perl5/5.6.0/sun4-solaris/CORE/perl.h", line 1929: warning: operand treated as unsigned: 0x87654321 "./mod_perl.h", line 584: warning: macro replacement within a string literal "./mod_perl.h", line 587: warning: macro replacement within a string literal "./mod_perl.h", line 590: warning: macro replacement within a string literal "./mod_perl.h", line 593: warning: macro replacement within a string literal "mod_perl.c", line 344: fatal: macro recursion cc: acomp failed for mod_perl.c *** Error code 2 make: Fatal error: Command failed for target `mod_perl.lo' Current working directory /tmp/mod_perl-1.23/apaci *** Error code 1 make: Fatal error: Command failed for target `apxs_libperl' radsun2-4%
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
Re: Problem with CGI::Carp under mod_perl
Gunther Birznieks wrote: > At 02:02 PM 4/18/00 +0100, Steve Hay wrote: > > >I'm having problems using "CGI::Carp qw(fatalsToBrowser);" in modperl > >scripts. > > Sorry for the late reply. I was actually trying to figure out why you were > experiencing this problem. I rarely use Perl 5.005 specific features, and > so I actually received reasonable results where you were not. > > It turns out that CGI::Carp does a specific check for Perl 5.005 and above > and uses a different mechanism that asks whether it is in an eval block. > Unfortunately the $^S variable gives information that is not precisely the > same as the error string parsing (for "eval") technique in it's > effectiveness under mod_perl. > > [snip] > > Go into your CGI::Carp.pm file and look for the > ineval() method. Manually edit it to remove the 5.005 check and just > compile an ineval() routine that is dependent on longmess() instead of $^S. Thanks very much for your reply, this works a treat under 5.005_03 and also my new Perl 5.6.0 / mod_perl 1.23 / Apache 1.3.12 setup which I'm testing out. This is a great help to me. I hope the change makes it into CGI::Carp -- have you heard anything from the author yet? > >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. > > This you cannot solve. Although CGI::Carp can catch fatal errors at script > startup because compile errors are fatal at that point. When a stirng is > eval'ed to compile the string into a set of data, though, those errors are > NOT fatal. They are warnings. > > Unfortunately, to get around this you would need to modify Apache::Registry > to trap warnings before compiling code and then die with a fatal error if > one of those warnings was a compile error. I can live without this, but it seems like an excellent idea. Any takers for doing it (I don't think I'm quite up to it myself...)? - Steve Hay
Re: Problem with CGI::Carp under mod_perl
Perrin Harkins wrote: > On Tue, 18 Apr 2000, Steve Hay wrote: > > > The first one calls die() itself. > [...] > > Sounds like a difference in the way CGI scripts and mod_perl buffer. I > fyou really want CGI::Carp to work, you need to make sure you don't send > any output before it gets called. Maybe you have PerlSendHeader on? I did have PerlSendHeader On: turning it off causes a DOS Prompt to pop up briefly, the die() message still goes to error.log and no output appears in the browser at all! > > The second one has a syntax error. > [...] > > CGI::Carp can't catch compile errors. Oh. The CGI::Carp manpage says (regarding the use of "set_message()" to control the output message): "In order to correctly intercept compile-time errors, you should call set_message() from within a BEGIN{} block. ", which suggests it does catch compile errors? I've tried both with "BEGIN {set_message('...')}" and without a set_message() at all, but to no avail. - Steve Hay
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.
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.
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
Re: Problem Compiling with Perl 5.6.0
> > $status = system "D:\\WINNT\\system32\\ipconfig.exe > > D:\\Temp\\ip.txt"; > > > > then it carries on fine under Apache (now re-directing the output to the > "ip.txt" > > file), but under Apache+mod_perl the $status gets set to 256, the "ip.txt" > file is > > not created and I get the error > > > > The handle could not be opened > > during redirection of handle 1. > > > > in error.log > > > > What is it that changed between Apache 1.3.6 (which doesn't have this > problem) and > > Apache 1.3.12 which causes this to happen, and can mod_perl be changed to > cope > > with it? > > Hi Steve, > I've tried this with the latest cvs mod_perl snapshot, like you > use, with Perl 5.6.0 and Apache_1.3.12. I'm using Win98, with the > 4DOS tools. As a cgi-bin script, > my $status = "ipconfig > C:\\test.txt" [I take it you meant 'my $status = system "ipconfig > C:\\test.txt";' here?!] > > returns $status = 0, and C:\test.txt capturing the output. > As an Apache::Registry script, the same thing returns > a status of 256 (with a DOS window briefly opening and > closing), but I get C:\test.txt still capturing the output. So it > may have something to do with the different DOS "shells"? Eh? I don't believe the DOS "shell" changed between Apache 1.3.6 and Apache 1.3.12!! The fact that you're running a different DOS "shell" to me does not explain the problem: it only explains why your experience of the problem it slightly different to mine. It was changing from Apache 1.3.6 to Apache 1.3.12 which broke it -- my DOS "shell" didn't change! And did you get the line in the error.log? Steve Hay
Re: Problem Compiling with Perl 5.6.0
Doug MacEachern wrote: > lemme guess, Perl_rsignal? somehow i managed not to commit this > yesterday, it's in cvs now. i don't have a win32 system to test on at the > moment, so any feeback from you, Randy K and others helps a great deal, > thanks. Great! I've just given the latest cvs another try, and for the first time that I've seen ApacheModulePerl.dll compiled and linked with 0 errors and 0 warnings. What's more, it even seems to work too after having given it a quick bashing. Unfortunately (for me, at least), I've still got the same problem which I had with Perl 5.005_03, namely that I can't re-direct STDOUT in system() calls. The following program works fine: $| = 1; print "Content-Type: text/plain\n\n"; $status = system "D:\\WINNT\\system32\\ipconfig.exe"; print "The system() call exited with status $status.\n"; (under Apache the output from IPCONFIG.EXE appears in the browser, under Apache+mod_perl it disappears somewhere, like the mod_perl Guide says it will, and $status is 0 both times). But, if I change: $status = system "D:\\WINNT\\system32\\ipconfig.exe"; to: $status = system "D:\\WINNT\\system32\\ipconfig.exe > D:\\Temp\\ip.txt"; then it carries on fine under Apache (now re-directing the output to the "ip.txt" file), but under Apache+mod_perl the $status gets set to 256, the "ip.txt" file is not created and I get the error The handle could not be opened during redirection of handle 1. in error.log What is it that changed between Apache 1.3.6 (which doesn't have this problem) and Apache 1.3.12 which causes this to happen, and can mod_perl be changed to cope with it? Steve Hay
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.
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...
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 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
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