Re: need your help to test mod_perl with perl-5.8.1-RC3
On Thu, Jul 31, 2003 at 01:27:01PM -0700, Michael G Schwern wrote: 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. Actually, try 6.13. That snapshot had a bug in it. -- Abandon failing tactics.
Re: need your help to test mod_perl with perl-5.8.1-RC3
Michael G Schwern wrote: On Thu, Jul 31, 2003 at 03:23:36PM +0100, Steve Hay wrote: This patch finally fixes it for me: I'm glad you guys got it working, but there's still the problem of why MakeMaker's behavior changed. Since I tend not to touch the XS building code much its likely a bug. Try the snapshot on makemaker.org. I just fixed a minor issue with argument passing in recursive builds. I just tried MM 6.13: that made no difference. Then I tried the snapshot (taken at 01 Aug 2003 07:55 UTC): that failed loads of its own tests, but made no difference to the libapreq build process. If I could see the Makefiles from 6.03 and 6.12 I might be able to figure out what's different. Also, if you could try various alpha versions between those two, show the Makefiles and whether or not they exhibited the behavior that would help alot in narrowing it down. I've also tried MM 6.05: that works OK. Attached are the various Makefiles (the top-level one, plus those from the c, Cookie and Request sub-directories), and a transcript of the nmake step, from a build using MM 6.05 (which worked) and another build using MM 6.12 (which failed). I'll move on to trying out those alpha versions and get back to you on which was the first one that failed. Steve makefiles.tar.gz Description: GNU Zip compressed data
Re: need your help to test mod_perl with perl-5.8.1-RC3
Steve Hay wrote: Michael G Schwern wrote: If I could see the Makefiles from 6.03 and 6.12 I might be able to figure out what's different. Also, if you could try various alpha versions between those two, show the Makefiles and whether or not they exhibited the behavior that would help alot in narrowing it down. I've also tried MM 6.05: that works OK. Attached are the various Makefiles (the top-level one, plus those from the c, Cookie and Request sub-directories), and a transcript of the nmake step, from a build using MM 6.05 (which worked) and another build using MM 6.12 (which failed). I'll move on to trying out those alpha versions and get back to you on which was the first one that failed. This bug evidently goes back a long way: MM 6.06_02 fails in the same way as 6.13. I tried to use MM 6.06_01, but it wouldn't build itself (don't know how to make 'C:\perl5\libNAME'). Instead, I knife-and-forked it into place, but when I tried to use it to build libapreq, I just got the same error again - don't know how to make 'C:\perl5\libNAME'. So the best I can offer you at this stage is that something between 6.05 and 6.06_02 broke it. (Probably not what you wanted to hear, I guess, looking at the number of changes in 6.06_01.) Steve
Re: need your help to test mod_perl with perl-5.8.1-RC3
Steve Hay wrote: This bug evidently goes back a long way: MM 6.06_02 fails in the same way as 6.13. I tried to use MM 6.06_01, but it wouldn't build itself (don't know how to make 'C:\perl5\libNAME'). Instead, I knife-and-forked it into place, but when I tried to use it to build libapreq, I just got the same error again - don't know how to make 'C:\perl5\libNAME'. OK, I've got MM 6.06_01 building now (it was generating broken Makefiles -- needed to change DIRFILESEP from \ to ^\, and fill in the missing *PERLSAFE macros), and the bad news is that it doesn't build libapreq-1.2 either! I still get the unresolved external symbol boot_libapreq error. So it's one of the many changes between 6.05 and 6.06_01 that broke it. Steve
Re: need your help to test mod_perl with perl-5.8.1-RC3
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'll tell you what beats voodoo every time, a big ass knife. -- Overkill Battlebot driver
handler help
Hi.
I need some help with handlers.
I'm a linux newbie. I freshly installed RH 9.
I built perl 5.8.0 from source.
As non-root, I downloaded source for
Apache 1.3.28 and mod_perl 1.28
and built them, using the instructions here
http://perl.apache.org/docs/1.0/guide/install.html#A_Summary_of_a_Basic_mod_perl_Installation
I've also been using Stas' book, Practical Mod Perl,
and the mod_perl developer's cookbook.
The only change I made to the
A_Summary_of_a_Basic_mod_perl_Installation
was using SU to root for the make install for
mod_perl.
The resulting Apache runs fine.
The resuling mod_perl runs cgi-scripts fine.
At times I'm running two servers on the same box, one
listening
to port 80 and one listening to port 8080.
I turned off the ssl piece of both servers, as they
were colliding
on port (I think) 443. I'm not sure if this 2 server
issue
or the turning ssl is relevant to my problem.
Now I'm trying to write my first mod_perl handler:
PerlModule Apache::HandlerTest
Location /handlertest
SetHandler perl-script
PerlHandler Apache::HandlerTest
/Location
package Apache::HandlerTest;
# File is called Apache/HandlerTest.pm
# Path:
/usr/lib/perl5/site_perl/5.8.0/Apache/HandlerTest.pm
sub handler {
my $r = shift; # Apache session object
$r-content_type('text/html');
$r-send_http_header;
$r-print( Hello, world. );
}
It dies with an
Internal Server Error
The server encountered an internal error or
misconfiguration and was unable to complete your
request
Here's the end of the log
[Thu Jul 31 18:34:08 2003] [error] [client
192.168.1.2] Can't locate object method content_type
via package Apache::RequestRec at
/usr/lib/perl5/site_perl/5.8.0/Apache/HandlerTest.pm
line 6.!
[Thu Jul 31 18:34:08 2003] [error] [client
192.168.1.2] File does not exist: /var/www/error
As the problem seesm related to finding things, I
tried making
the handler simpler by using no functions
sub handler {
print HTTP/1.0 200 OK\n;
print Content-Type: text/html\n\n;
print htmlbodyHello/body/html;
return 200;
}
This didn't work either --
[Thu Jul 31 18:42:57 2003] [error] [client
192.168.1.2] Can't locate object method PRINT via
package Apache::RequestRec at
/usr/lib/perl5/site_perl/5.8.0/Apache/HandlerTest.pm
line 13.!
[Thu Jul 31 18:42:57 2003] [error] [client
192.168.1.2] File does not exist: /var/www/error
I guess the print is really a call to $r-print()
(Practical Mod_perl p 238).
This newcoming to mod-perl seeks any help on next
steps.
RKG
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Skipped Tests (was: handler help)
Hi -- I'm following up on a previous message (below), sorry to break the thread in two. In my first post, I was wondering my handler didn't work. I said make test worked fine for mod_perl. Well, maybe. Here's the output. [EMAIL PROTECTED]:~/source/mod_perl-1.28 make test (cd ../apache_1.3.28 PERL5LIB=/home/aprk/source/mod_perl-1.28/lib: make) make[1]: Entering directory `/home/aprk/source/apache_1.3.28' === src make[2]: Entering directory `/home/aprk/source/apache_1.3.28' make[3]: Entering directory `/home/aprk/source/apache_1.3.28/src' === src/regex make[4]: Nothing to be done for `all'. === src/regex === src/os/unix make[4]: Nothing to be done for `all'. === src/os/unix === src/ap make[4]: Nothing to be done for `all'. === src/ap === src/main make[4]: Nothing to be done for `all'. === src/main === src/lib === src/lib === src/modules === src/modules/standard make[5]: Nothing to be done for `all'. === src/modules/standard === src/modules/perl make[5]: Nothing to be done for `all'. === src/modules/perl === src/modules cc -c -I. -I/usr/local/lib/perl5/5.8.0/i686-linux/CORE -I./os/unix -I./include -DLINUX=22 -DMOD_PERL -DUSE_PERL_SSI -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -DUSE_HSREGEX -DNO_DL_NEEDED -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm `./apaci` modules.c cc -c -I. -I/usr/local/lib/perl5/5.8.0/i686-linux/CORE -I./os/unix -I./include -DLINUX=22 -DMOD_PERL -DUSE_PERL_SSI -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -DUSE_HSREGEX -DNO_DL_NEEDED -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm `./apaci` buildmark.c cc -DLINUX=22 -DMOD_PERL -DUSE_PERL_SSI -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -DUSE_HSREGEX -DNO_DL_NEEDED -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm `./apaci`\ -o httpd buildmark.o modules.o modules/standard/libstandard.a modules/perl/libperl.a main/libmain.a ./os/unix/libos.a ap/libap.a regex/libregex.a -lm -lcrypt -rdynamic -L/usr/local/lib /usr/local/lib/perl5/5.8.0/i686-linux/auto/DynaLoader/DynaLoader.a -L/usr/local/lib/perl5/5.8.0/i686-linux/CORE -lperl -lnsl -ldl -lm -lc -lcrypt -lutil make[3]: Leaving directory `/home/aprk/source/apache_1.3.28/src' make[2]: Leaving directory `/home/aprk/source/apache_1.3.28' make[2]: Entering directory `/home/aprk/source/apache_1.3.28' === src/support make[3]: Entering directory `/home/aprk/source/apache_1.3.28/src/support' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/aprk/source/apache_1.3.28/src/support' === src/support make[2]: Leaving directory `/home/aprk/source/apache_1.3.28' === src make[1]: Leaving directory `/home/aprk/source/apache_1.3.28' make[1]: Entering directory `/home/aprk/source/mod_perl-1.28/Apache' make[1]: Leaving directory `/home/aprk/source/mod_perl-1.28/Apache' make[1]: Entering directory `/home/aprk/source/mod_perl-1.28/Connection' make[1]: Leaving directory `/home/aprk/source/mod_perl-1.28/Connection' make[1]: Entering directory `/home/aprk/source/mod_perl-1.28/Constants' make[1]: Leaving directory `/home/aprk/source/mod_perl-1.28/Constants' make[1]: Entering directory `/home/aprk/source/mod_perl-1.28/File' make[1]: Leaving directory `/home/aprk/source/mod_perl-1.28/File' make[1]: Entering directory `/home/aprk/source/mod_perl-1.28/Leak' make[1]: Leaving directory `/home/aprk/source/mod_perl-1.28/Leak' make[1]: Entering directory `/home/aprk/source/mod_perl-1.28/Log' make[1]: Leaving directory `/home/aprk/source/mod_perl-1.28/Log' make[1]: Entering directory `/home/aprk/source/mod_perl-1.28/ModuleConfig' make[1]: Leaving directory `/home/aprk/source/mod_perl-1.28/ModuleConfig' make[1]: Entering directory `/home/aprk/source/mod_perl-1.28/PerlRunXS' make[1]: Leaving directory `/home/aprk/source/mod_perl-1.28/PerlRunXS' make[1]: Entering directory `/home/aprk/source/mod_perl-1.28/Server' make[1]: Leaving directory `/home/aprk/source/mod_perl-1.28/Server' make[1]: Entering directory `/home/aprk/source/mod_perl-1.28/Symbol' make[1]: Leaving directory `/home/aprk/source/mod_perl-1.28/Symbol' make[1]: Entering directory `/home/aprk/source/mod_perl-1.28/Table' make[1]: Leaving directory `/home/aprk/source/mod_perl-1.28/Table' make[1]: Entering directory `/home/aprk/source/mod_perl-1.28/URI' make[1]: Leaving directory `/home/aprk/source/mod_perl-1.28/URI' make[1]: Entering directory `/home/aprk/source/mod_perl-1.28/Util' make[1]: Leaving directory `/home/aprk/source/mod_perl-1.28/Util' cp t/conf/mod_perl_srm.conf t/conf/srm.conf ../apache_1.3.28/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t httpd listening on port 8529 will write error_log to: t/logs/error_log letting apache warm up...\c done /usr/local/bin/perl t/TEST 0 modules/actions...ok modules/cgi...ok modules/constants.ok modules/cookieskipped all
Re: uwinnipeg site down (ppm installation)?
Sorry about this - I had a hard disc crash, and am just in the process of restoring things. Computers are getting too smart - they know when you're vulnerable, and will act accordingly ... Hopefully it'll be ready in a day. No worries, things like these happen. In the mean time, do you know of a mirror where I could get the files? I'm trying to get mod_perl installed and get all the web scripts we have here working on it, and I would like to be able to work on it today if possible... If not, I'll wait until Monday, no problem. Thanks, J-S ___ Jean-Sébastien Guay [EMAIL PROTECTED] Software Developer, Hybride http://www.hybride.com Piedmont, Québec, Canada
Re: Skipped Tests (was: handler help)
Hi there, On Fri, 1 Aug 2003, Tofu Optimist wrote: sorry to break the thread in two. :( Why did it skip 6 tests? How did you do the perl Makefile.PL step? 73, Ged.
Re: Skipped Tests (was: handler help)
Exactly like it said in http://perl.apache.org/docs/1.0/guide/install.html#A_Summary_of_a_Basic_mod_perl_Installation % cd /usr/src % lwp-download http://www.apache.org/dist/httpd/apache_1.3.xx.tar.gz % lwp-download http://perl.apache.org/dist/mod_perl-1.xx.tar.gz % tar xzvf apache_1.3.xx.tar.gz % tar xzvf mod_perl-1.xx.tar.gz % cd mod_perl-1.xx % perl Makefile.PL APACHE_SRC=../apache_1.3.xx/src \ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 % make make test make install % cd ../apache_1.3.xx % make install --- Ged Haywood [EMAIL PROTECTED] wrote: Hi there, On Fri, 1 Aug 2003, Tofu Optimist wrote: sorry to break the thread in two. :( Why did it skip 6 tests? How did you do the perl Makefile.PL step? 73, Ged. __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: Skipped Tests (was: handler help)
Hello again, On Fri, 1 Aug 2003, Tofu Optimist wrote: --- Ged Haywood [EMAIL PROTECTED] wrote: How did you do the perl Makefile.PL step? % cd /usr/src % tar xzvf apache_1.3.xx.tar.gz % tar xzvf mod_perl-1.xx.tar.gz % cd mod_perl-1.xx % perl Makefile.PL APACHE_SRC=../apache_1.3.xx/src DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 So your non-root user has write permission in /usr/src? H... % make make test make install This can't work, you need to be root to make install. 73, Ged. PS: Did you build your own Perl? Have you cleaned up any old Apaches and mod_perls? (RH9 comes with Apache2, you probably want to get rid of that:).
Re: Skipped Tests (was: handler help)
Ged -- Sorry I wasn't fully explicit, it is still early in the morning: So your non-root user has write permission in /usr/src? H... Rather than /usr/src, I put in /home/aprk % make make test make install This can't work, you need to be root to make install. Yes, you are correct. make make test as non-root, then install as root. (Odd, isn't it, the docs at http://perl.apache.org/docs/1.0/guide/install.html#A_Summary_of_a_Basic_mod_perl_Installation don't make this explicit?) PS: Did you build your own Perl? Yes, 5.8.0 Have you cleaned up any old Apaches and mod_perls? (RH9 comes with Apache2, you probably want to get rid of that:). Excellent point. No. There are probably hordes of perls and hpptds and mod_perls running amok on the box throwing wild parties; I don't know. I think my next step should be to start over fresh. Again. As a newbie, may I ask 4 basic questions: [1] How do I find *everything* on the box related to perl / apache / mod_perl, both 1 and 2, both the RH install and from my own ftp / tar / make fumblings? [2] How do I uninstall everything from [1], so I can start fresh? [3] I'd prefer to use modperl 2 and apache 2, as that is what my ISP is using. And I think I'd prefer to use RH rpm to install them, as again, that is what my ISP did. (Want my dev box to match the outside box as much as possible). This newsgroup keeps mentioning build from sources, will I be going astray trying the rpm route? [4] Is a full uninstall enough, or should I reinstall RH itself? Many thanks for your generosity explaining these mysteries to a newcomer. -- A __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: handler help
On Fri, 2003-08-01 at 07:02, Tofu Optimist wrote: I'm a linux newbie. I freshly installed RH 9. I built perl 5.8.0 from source. Go and change your locale from UTF8 to en_US or C. See this for why: http://archive.develooper.com/[EMAIL PROTECTED]/msg97360.html As non-root, I downloaded source for Apache 1.3.28 and mod_perl 1.28 and built them, using the instructions here http://perl.apache.org/docs/1.0/guide/install.html#A_Summary_of_a_Basic_mod_perl_Installation Okay... [Thu Jul 31 18:34:08 2003] [error] [client 192.168.1.2] Can't locate object method content_type via package Apache::RequestRec at /usr/lib/perl5/site_perl/5.8.0/Apache/HandlerTest.pm line 6.! That's mod_perl 2. (There is Apache::RequestRec in mod_perl 1.) You must have an older one on your box and you are trying to run this handler with it. Figure out where you installed mod_perl 1 and use that instead. - Perrin
Re: Skipped Tests (was: handler help)
On Fri, 2003-08-01 at 10:31, Tofu Optimist wrote: [1] How do I find *everything* on the box related to perl / apache / mod_perl, both 1 and 2, both the RH install and from my own ftp / tar / make fumblings? Well, you can run updatedb and then use locate to look for things like apachectl and Apache.pm. [2] How do I uninstall everything from [1], so I can start fresh? There is no simply way to uninstall software that you installed from source. There are things you can do though. First uninstall any apache or mod_perl rpms. Then you can clear out all the Apach::* modules from your perl lib, and delete all the web server stuff (which is typically installed under a single directory). [3] I'd prefer to use modperl 2 and apache 2, as that is what my ISP is using. Okay, then stop reading docs for mod_perl 1. And I think I'd prefer to use RH rpm to install them, as again, that is what my ISP did. Don't do that. mod_perl 2 is basically in alpha right now and changes every day. If you plan to run it, you must keep on top of development. The rpms for mod_perl 2 are ancient at this point. [4] Is a full uninstall enough, or should I reinstall RH itself? The latter is more complete, but if you don't see any more httpd.conf files or Apache:: modules, you have probably cleaned things close enough. - Perrin
[mp1] Apache::Reload questions...
I've been working with Apache::Reload and Registry and have been unable to get any cache flushing to work. (I've added debug messages in Registry to show cache use or reloading). I've tried this combination: (httpd.conf) PerlModule Apache::RegistryPerlModule Apache::StatusPerlInitHandler Apache::ReloadPerlSetVar ReloadAll On And also this: PerlModule Apache::RegistryPerlModule Apache::StatusPerlInitHandler Apache::ReloadPerlSetVar ReloadAll OnPerlSetVar ReloadTouchFile /tmp/reload_modules No dice. Any suggestions? Apache 1.3.27, mod-perl 1.27 is the config. Roger
[MP1 and MP2] Apache-AuthenNIS ported
The uploaded file Apache-AuthenNIS-0.11.tar.gz has entered CPAN as file: $CPAN/authors/id/S/SP/SPEEVES/Apache-AuthenNIS-0.11.tar.gz size: 4095 bytes md5: cac172a46c5b05034842fad5eed6b9be Apache::AuthenNIS - mod_perl NIS Authentication module has been ported to work with both versions of modperl. thanks, speeves cws
Re: Skipped Tests (was: handler help)
Hi there, On Fri, 1 Aug 2003, Tofu Optimist wrote: Rather than /usr/src, I put in /home/aprk That's fine. But in future, tell us what you did, not some fiction... :) Yes, you are correct. make make test as non-root, then install as root. (Odd, isn't it, the docs at http://perl.apache.org/docs/1.0/guide/install.html#A_Summary_of_a_Basic_mod_perl_Installation don't make this explicit?) Yes, I always think that, but many of the Open Source packages neglect to mention this point every time it might be mentioned. I think authors expect it to be either very obvious or else perhaps unnecessary - some operating systems don't have a Unix-like permisisons system. Did you build your own Perl? Yes, 5.8.0 Good. You might want to try 5.8.1 soon, but I don't think that's a problem here. Have you cleaned up any old Apaches and mod_perls? No. There are probably hordes of perls and hpptds and mod_perls running amok on the box throwing wild parties; I don't know. Argh. The Apache2/modperl2 that comes with RH9 is junk. Get rid of it all. Use 'ps' to see what processes you have running and stop any httpd processes that you don't think you started. RH will start an Apache when it boots if you let it, I wish they wouldn't do that. Read 'man chkconfig'. Go into /etc/rc.d and look at the startup scripts. Use chkconfig to prevent Apache being started at boot so you can start it manually when you've built it. When you're happy that it's all as you wnt it, you might want to use chkconfig to set it up to start at boot again. I think my next step should be to start over fresh. Again. :) [1] How do I find *everything* on the box related to perl / apache / mod_perl, both 1 and 2, both the RH install and from my own ftp / tar / make fumblings? [2] How do I uninstall everything from [1], so I can start fresh? Well RH should let you uninstall packages with rpm, but I don't use rpm and I tend to avoid RedHat so I don't know exactly how you'd do it. My preference would be to look in /usr/local/ and /var/lib to see if there are any apache things such as /usr/local/apache, and if so go in there as root and rm -rf the entire apache directory. That will perhaps throw away config files etc. you've been working on, you might want to make backups. When you've done that you might want to use slocate to build a database of filenames on your filesystem, then use it to search for any httpd or apachectl files that escaped. If so there'll probably be truckloads of files in there with them. Nukem. The source trees in your home directory don't matter. Nuke them too. You won't need to do anything about Perl on your system if you really did compile it from source yourself. [3] I'd prefer to use modperl 2 and apache 2, as that is what my ISP is using. And I think I'd prefer to use RH rpm to install them, as again, that is what my ISP did. (Want my dev box to match the outside box as much as possible). This newsgroup keeps mentioning build from sources, will I be going astray trying the rpm route? I hate RPMs. For Apache2/modperl2 you would be better off going to the CVS sources unless you can get hold of a very recent RPM, things are changing really fast in the mod_perl version 2 codebase. True, it could be important for your dev box to match your prod box, but when you figure out what's going on it will probably matter less - until you start doing really fancy stuff, when it will start to matter again. [4] Is a full uninstall enough, or should I reinstall RH itself? No, don't reinstall the entire OS. Get used to what your system feels like and eventually you'll know what to leave alone and what to change. mysteries to a newcomer. FWIW you sound like you're picking it up quickly. 73, Ged.
[MP1 and MP2] Apache::AuthzNIS ported
The uploaded file Apache-AuthzNIS-0.11.tar.gz has entered CPAN as file: $CPAN/authors/id/S/SP/SPEEVES/Apache-AuthzNIS-0.11.tar.gz size: 4305 bytes md5: 37bbbdc320c6bba7318d817e854bc8e1 Apache::AuthzNIS - mod_perl NIS Group Authorization module has been ported to work with both versions of modperl. thanks, speeves
Re: uwinnipeg site down (ppm installation)?
Sorry about this - I had a hard disc crash, and am just in the process of restoring things. Computers are getting too smart - they know when you're vulnerable, and will act accordingly ... Hopefully it'll be ready in a day. Great job Randy! Got mod_perl installed, so I can now start bashing my code to see how much punishment it needs before agreeing to run on it! :-) Thanks! J-S
Re: [mp1] Apache::Reload questions...
On Fri, 2003-08-01 at 11:10, Roger Davenport wrote: I've been working with Apache::Reload and Registry and have been unable to get any cache flushing to work. (I've added debug messages in Registry to show cache use or reloading). Can you tell us what you are trying to reload and how you know it is isn't happening? Keep in mind, Apache::Reload has nothing to do with reloading Registry scripts. That reloading is handled entirely within Registry itself. - Perrin
Cookies, CGI::App, and mod_perl
Hello all, I am using CGI::App 3.1, Apache 1.3.27 and mod_perl 1.28 Here's the problem. I'm trying to set a cookie (using CGI's cookie method and C::A's header_props method). When the site was running non mod_perl there was no problem. The cookie was set. When running under mod_perl the cookie is no where to be seen. If I understand this correctly, then C::A uses CGI to set the cookie and CGI should set it correctly if I'm running under mod_perl right? I've seen a lot on forums to use Apache::Cookie, but how do I do that within C::A? Any ideas would be appreciated. Thanks Michael Peters Venzia
Re: Cookies, CGI::App, and mod_perl
On Fri, 2003-08-01 at 13:04, petersm wrote: When running under mod_perl the cookie is no where to be seen. Do some debugging. Look at the traffic going back and forth. Test it with GET or lynx. See if the cookie header is being sent. If I understand this correctly, then C::A uses CGI to set the cookie and CGI should set it correctly if I'm running under mod_perl right? Right, although I don't think C::A knows or cares at all about cookies. This is just between you and CGI.pm. I've seen a lot on forums to use Apache::Cookie, but how do I do that within C::A? You don't need to use Apache::Cookie, but if you want to you should be able to use it in the normal documented way. C::A should not have any bearing on this. - Perrin
Module caching
Hello all, I am working on a large modperl app, and one of the features of this is a plugin system that allows others to write and install modules. Everything is good as far as this goes, but the problem is updateing/deleting modules. It seems as though the code is cached until an apache restart (i.e code changes don't take effect, version numbers don't change). Is there a way to flush the INC hash of all the children programmatically, without a restart? I have looked at Apache::Reload and Apache::StatINC and tried to replicate the code, but it doesn't seem to be working. Thanks, Scott
Re: Module caching
On Fri, 2003-08-01 at 13:42, Scott wrote: I have looked at Apache::Reload and Apache::StatINC And what was wrong with them? You should know that there is no perfect way to reload a Perl module. It just isn't a feature of the language. Those two modules come as close as you can get without actually starting a new interpreter, but it is still possible for some code (especially code using closures) to interact badly with them. - Perrin
Re: Cookies, CGI::App, and mod_perl
[ Please keep it on the list... ] On Fri, 2003-08-01 at 14:06, petersm wrote: Perrin Harkins [EMAIL PROTECTED] wrote Do some debugging. Look at the traffic going back and forth. Test it with GET or lynx. See if the cookie header is being sent. Thanks for the suggestion. I used wget and tried it with the mod_perl stuff in the config and without. Without, wget gave me the header with the cookie. With, wget did not have a cookie in the header. Both returned the correct HTML. Maybe some a glance at my config file could help. So here's the relavant portion. Thanks... PerlModule Apache::StatINC Location /operations/projects/menagerie AddHandler perl-script .cgi PerlHandler Apache::Registry PerlSendHeader On allow from all PerlInitHandler Apache::StatINC PerlSetVar StatINCDebug On PerlSetEnv PERL5LIB /development/operations/projects/ /Location That looks okay to me. Maybe it's something about the way you've structured your code. Try reducing it down to a small snippet that you can post. You may also want to ask on the CGI::Application list. - Perrin
GlobalRequest
Hello, I'm fairly new at mod_perl, and trying to get a large number of existing Perl CGI scripts to run on it. I have started by trying to start the server with a minimal startup.pl file that just loads one of my custom modules (in addition to the ones that were suggested in the mod_perl configuration docs). I get this error: [Fri Aug 01 13:49:05 2003] [error] Global $r object is not available. Set: PerlOptions +GlobalRequestin httpd.conf at D:/Perl/lib/CGI.pm line 269.Compilation failed in require at D:/htdocs/startup.pl line 32.BEGIN failed--compilation aborted at D:/htdocs/startup.pl line 32.Compilation failed in require at (eval 1) line 1. [Fri Aug 01 13:49:05 2003] [error] Can't load Perl file: D:/htdocs/startup.pl forserver bob.bob.com:80, exiting... (of course, startup.pl line 32 is the line where I use() my own module) Now, from reading the docs (http://perl.apache.org/docs/2.0/user/config/config.html#toc_C_GlobalRequest_), I saw : This setting is enabled by default for sections configured as: Location ... SetHandler perl-script ... /Location Which is my case. And even if I add+GlobalRequest to the PerlOptions line in my mod_perl Location section, I get the same error. Is there anything else I need to do? Thanks in advance, J-S ___Jean-Sébastien Guay [EMAIL PROTECTED]Software Developer, Hybride http://www.hybride.comPiedmont, Québec, Canada
Current directory
Hello again, I have another problem trying to get one of my Perl modules to load in my startup.pl script for the first time. In a couple places in my scripts, I assume that the current directory is the one in which the current script is being run. So for example, if my DocumentRoot is D:/htdocs/ and someone requests http://myhostname/script.cgi, if I need touse some files, my current directory is D:/htdocs. The two things I currently do this for are a) configuration file, which is loaded on startup by the module I am trying to get loaded in my startup.pl script b) templates (for template-toolkit), which I specify to be in the directory 'templates' relative to the location where the scripts are running, meaning they are in D:/htdocs/templates. I see only disadvantages to having to specify absolute paths in both these cases. For one, I have another web server running on port 8080, which I use to test my scripts on, and whose DocumentRoot is D:/htdocs-dev. So if I had to manually change the paths each time I copied files over from the development DocumentRoot to the production one, I would go crazy. Is there a way to guarantee that the current directory will be the correct one when I need it to? Or does anyone have another suggestion? Thanks! J-S ___Jean-Sébastien Guay [EMAIL PROTECTED]Software Developer, Hybride http://www.hybride.comPiedmont, Québec, Canada
Re: Skipped Tests (was: handler help)
Thanks Ged. [4] Is a full uninstall enough, or should I reinstall RH itself? No, don't reinstall the entire OS. Get used to what your system feels like and eventually you'll know what to leave alone and what to change. Well, I opted to reinstall everything, starting with a fresh RH9. Then I removed all the relevant RH9 RPMS: [EMAIL PROTECTED] root]# rpm -e mod_ssl [EMAIL PROTECTED] root]# rpm -e mod_python [EMAIL PROTECTED] root]# rpm -e pho [EMAIL PROTECTED] root]# rpm -e php-ldap [EMAIL PROTECTED] root]# rpm -e php-imap [EMAIL PROTECTED] root]# rpm -e php [EMAIL PROTECTED] root]# rpm -e redhat-config-httpd [EMAIL PROTECTED] root]# rpm -e webalizer [EMAIL PROTECTED] root]# rpm -e mod_perl [EMAIL PROTECTED] root]# rpm -e httpd (I had to take out mod_ssl, mod_python, etc so as to free up dependencies.) MY QUESTION: Now I want to remove perl, too: [EMAIL PROTECTED] root]# rpm -e perl error: Failed dependencies: perl is needed by (installed) logwatch-4.3.1-2 perl is needed by (installed) w3m-0.3.2.2-5 perl = 0:5.002 is needed by (installed) perl-Filter-1.29-3 perl = 0:5.00503 is needed by (installed) perl-DateManip-5.40-30 perl = 0:5.000 is needed by (installed) perl-DateManip-5.40-30 perl = 0:5.00503 is needed by (installed) perl-HTML-Tagset-3.03-28 perl = 1:5 is needed by (installed) perl-HTML-Tagset-3.03-28 perl = 5.6.0 is needed by (installed) perl-HTML-Parser-3.26-17 perl = 0:5.004 is needed by (installed) perl-HTML-Parser-3.26-17 perl = 0:5.00503 is needed by (installed) perl-Parse-Yapp-1.05-30 perl = 0:5.004 is needed by (installed) perl-Parse-Yapp-1.05-30 perl = 0:5.00503 is needed by (installed) perl-URI-1.21-7 perl = 0:5.00503 is needed by (installed) perl-libwww-perl-5.65-6 perl = 0:5.002 is needed by (installed) perl-libwww-perl-5.65-6 perl = 0:5.004 is needed by (installed) perl-libwww-perl-5.65-6 perl = 0:5.005 is needed by (installed) perl-libwww-perl-5.65-6 perl = 2:5.8.0 is needed by (installed) perl-XML-Parser-2.31-15 perl = 0:5.004 is needed by (installed) perl-XML-Parser-2.31-15 perl = 5.6.0 is needed by (installed) perl-libxml-perl-0.07-28 perl = 0:5.005 is needed by (installed) perl-libxml-perl-0.07-28 perl = 5.6.0 is needed by (installed) perl-XML-Dumper-0.4-25 perl = 5.6.0 is needed by (installed) perl-XML-Encoding-1.01-23 perl = 0:5.005 is needed by (installed) perl-XML-Encoding-1.01-23 perl = 0:5.00503 is needed by (installed) perl-libxml-enno-1.02-29 perl = 5.6.0 is needed by (installed) perl-XML-Grove-0.46alpha-25 perl = 0:5.005 is needed by (installed) perl-XML-Grove-0.46alpha-25 perl = 0:5.004 is needed by (installed) perl-XML-Twig-3.09-3 perl = 5.6.1 is needed by (installed) foomatic-2.0.2-15 perl is needed by (installed) redhat-config-printer-0.6.47-1 perl = 1:5 is needed by (installed) emacs-21.2-33 perl is needed by (installed) libgnomeprint22-2.2.1.1-3 perl is needed by (installed) docbook-dtds-1.0-17 perl is needed by (installed) libgnomeprint-1.116.0-6 perl is needed by (installed) desktop-printing-0.1.10-6 perl = 1:5 is needed by (installed) xscreensaver-4.07-2 perl is needed by (installed) autoconf-2.57-3 perl = 0:5.000 is needed by (installed) autoconf-2.57-3 perl = 0:5.005_03 is needed by (installed) autoconf-2.57-3 perl is needed by (installed) automake14-1.4p6-5.1 perl is needed by (installed) automake15-1.5-6 perl = 0:5.005 is needed by (installed) automake15-1.5-6 Now, in this forum I heard the importance of building perl with the same compiler that you use for httpd and mod_perl. Am I going to have problems following the MP 2.0 install instructions http://perl.apache.org/docs/2.0/user/install/install.html if I don't nuke the current perl first? Thanks. And this time I'll restrict my reading to the 2.0 install docs, rather than dipping back into the 1.0 docs in the middle of 2.0 install. (Doh!) Thanks for advice on this -- A Did you build your own Perl? Yes, 5.8.0 Good. You might want to try 5.8.1 soon, but I don't think that's a problem here. Have you cleaned up any old Apaches and mod_perls? No. There are probably hordes of perls and hpptds and mod_perls running amok on the box throwing wild parties; I don't know. Argh. The Apache2/modperl2 that comes with RH9 is junk. Get rid of it all. Use 'ps' to see what processes you have running and stop any httpd processes that you don't think you started. RH will start an Apache when it boots if you let it, I wish they wouldn't do that. Read 'man chkconfig'. Go into /etc/rc.d and look at the startup scripts. Use chkconfig to prevent Apache being started at boot so you can start it manually when you've built it. When you're
Re: Skipped Tests (was: handler help)
On Fri, 2003-08-01 at 16:24, Tofu Optimist wrote: Am I going to have problems following the MP 2.0 install instructions http://perl.apache.org/docs/2.0/user/install/install.html if I don't nuke the current perl first? No, you should be fine. However, I have also simply installed a new perl on top of the one shipped by RH with no problems. (I did this because I wanted to use 5.6.1 rather than 5.8.0.) You will be blowing the RPM system by doing that, so it's not an advisable way to handle a large cluster of machines, but it works fine if you just need to get a quick dev environment bootstrapped. - Perrin
Re: Current directory
On Fri, 2003-08-01 at 15:46, Jean-Sebastien Guay wrote: I see only disadvantages to having to specify absolute paths in both these cases. For one, I have another web server running on port 8080, which I use to test my scripts on, and whose DocumentRoot is D:/htdocs-dev. So if I had to manually change the paths each time I copied files over from the development DocumentRoot to the production one, I would go crazy. There are dozens of possible answers to this. I typically put things relative to the web server root, which is described here: http://perl.apache.org/docs/1.0/api/Apache.html#Apache_E_gt_server_root_relativerelative_path___ Another approach would be to look up the directory that your script is in and either chdir to that or pass it to your modules and have them use it. There are also common approaches like passing some kind of application root either in an environment variable or in httpd.conf with a PerlSetVar. - Perrin
Re: GlobalRequest
On Fri, 2003-08-01 at 14:20, Jean-Sebastien Guay wrote: [Fri Aug 01 13:49:05 2003] [error] Global $r object is not available. Set: PerlOptions +GlobalRequest in httpd.conf at D:/Perl/lib/CGI.pm line 269. Make sure you have the very latest CGI.pm. There were some changes related to mod_perl 2 recently. - Perrin
Re: uwinnipeg site down (ppm installation)?
On Fri, 1 Aug 2003, Jean-Sebastien Guay wrote: Sorry about this - I had a hard disc crash, and am just in the process of restoring things. Computers are getting too smart - they know when you're vulnerable, and will act accordingly ... Hopefully it'll be ready in a day. Great job Randy! Got mod_perl installed, so I can now start bashing my code to see how much punishment it needs before agreeing to run on it! :-) I think most things are working now - please let me know if something major's amiss ... I've copied the ppm packages also over to http://perl.apache.org/dist/win32-bin/, so they can also be accessed there. best regards, randy
Re: Current directory
Hi Perrin,
Thanks for both your answers. Indeed, for the other question, I was using
CGI 2.91 instead of 2.93 (because that one isn't yet available for Perl 5.8
via PPM). I'll find a way to upgrade it.
There are dozens of possible answers to this.
...
There are also common approaches like passing some kind of application
root either in an environment variable or in httpd.conf with a
PerlSetVar.
Unfortunately, this doesn't seem to work. Even if I put the PerlSetVar
statement before my PerlRequire statement like so:
PerlSetVar SCRIPT_ROOT D:/htdocs
PerlRequire D:/htdocs/_startup.pl
the module, which is then loaded from _startup.pl, sees only undef when I
try to print $ENV{SCRIPT_ROOT}; ... I also tried to do this right before
use()ing my module:
$ENV{SCRIPT_ROOT} = 'D:/htdocs';
and it gives the same result. Could the problem come from the fact that
_startup.pl is trying to load the module before Apache is actually finished
loading, so the environment is not in a valid state at that point? What else
could cause this?
Thanks,
J-S
___
Jean-Sébastien Guay [EMAIL PROTECTED]
Software Developer, Hybride http://www.hybride.com
Piedmont, Québec, Canada
Re: uwinnipeg site down (ppm installation)?
I've copied the ppm packages also over to http://perl.apache.org/dist/win32-bin/, so they can also be accessed there. Great, always good to have mirrors. J-S
Re: Current directory
On Fri, 2003-08-01 at 16:59, Jean-Sebastien Guay wrote:
Unfortunately, this doesn't seem to work. Even if I put the PerlSetVar
statement before my PerlRequire statement like so:
PerlSetVar SCRIPT_ROOT D:/htdocs
PerlRequire D:/htdocs/_startup.pl
the module, which is then loaded from _startup.pl, sees only undef when I
try to print $ENV{SCRIPT_ROOT};
You're thinking of PerlSetEnv. PerlSetVar values are retrieved
differently. Take a look at this:
http://perl.apache.org/docs/1.0/guide/config.html#PerlSetEnv_and_PerlPassEnv
Note that you can also just do this:
Perl
$MyConfig::SCRIPT_ROOT = 'foo';
/Perl
And then in your module:
my $root = $MyConfig::SCRIPT_ROOT;
- Perrin
Re: Current directory
On Fri, 1 Aug 2003, Jean-Sebastien Guay wrote: Hi Perrin, Thanks for both your answers. Indeed, for the other question, I was using CGI 2.91 instead of 2.93 (because that one isn't yet available for Perl 5.8 via PPM). I'll find a way to upgrade it. One way is to configure the CPAN module: C:\ perl -MCPAN -e shell which, the first time you invoke it, will lead you through a dialogue. You can accept most of the defaults, except for the list of CPAN mirrors to use. Then, at the CPAN.pm shell prompt, you can say cpan install CGI Before doing this, you'll need Microsoft's nmake utility; a link on where to get it appears in the Win32 configuration page at http://perl.apache.org/. best regards, randy
Re: Skipped Tests (was: handler help)
Ack!! My perl build failed. Here's what I did nuke the RPMS [EMAIL PROTECTED] root]# rpm -e mod_ssl [EMAIL PROTECTED] root]# rpm -e mod_python [EMAIL PROTECTED] root]# rpm -e pho [EMAIL PROTECTED] root]# rpm -e php-ldap [EMAIL PROTECTED] root]# rpm -e php-imap [EMAIL PROTECTED] root]# rpm -e php [EMAIL PROTECTED] root]# rpm -e redhat-config-httpd [EMAIL PROTECTED] root]# rpm -e webalizer [EMAIL PROTECTED] root]# rpm -e httpd [EMAIL PROTECTED] root]# rpm -e mod_perl download perl, apache, mod_perl ls -rw-rw-r--1 aprk aprk 6260081 Jul 7 11:09 httpd-2.0.47.tar.gz -rw-rw-r--1 aprk aprk 918029 Apr 27 22:53 mod_perl-2.0-current.tar.gz -rw---1 aprk aprk 4145152 Aug 1 16:48 perl-5.8.0.tar.gz unzip and untar them, then cd perl-5.8.0 ./Configure -des make make test Here's the failure Failed Test Stat Wstat Total Fail Failed List of Failed --- ../lib/Locale/Codes/t/all.t 20 2 10.00% 9-10 ../lib/Locale/Codes/t/languages.t 59 1 1.69% 22 42 tests and 406 subtests skipped. Failed 2/712 test scripts, 99.72% okay. 3/68552 subtests failed, 100.00% okay. Oh helpful gurus, any advice? With gratitude -- A __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Re: Skipped Tests (was: handler help)
On Fri, 2003-08-01 at 17:46, Tofu Optimist wrote: Ack!! My perl build failed. [...] Failed Test Stat Wstat Total Fail Failed List of Failed --- ../lib/Locale/Codes/t/all.t 20 2 10.00% 9-10 ../lib/Locale/Codes/t/languages.t 59 1 1.69% 22 42 tests and 406 subtests skipped. Failed 2/712 test scripts, 99.72% okay. 3/68552 subtests failed, 100.00% okay. You didn't follow my earlier advice about changing the locale, did you? I wasn't kidding about that. You can't build perl 5.8.0 successfully on a RH 9 system unless you change the locale. Note that 5.8.1 does not have this problem and is about to be released. - Perrin
Re: Skipped Tests (was: handler help)
I'm not TRYING to be difficult; I am clueless. :) Exactly HOW do I change the locale? And after I do that, I do my make make install again, yes? Many thanks! :) A __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com
Apache::ProxyRewrite possible bug with port numbers on ProxyRewrite
I've been kicking around a proxy server here and found your Apache-ProxyRewrite most useful but I have this quirk perhaps you can help with. I'm using version 0.17. I've read in the ChangeLog that one of the more recent fixes (v0.16) may have been to address the problem I'm encountering. Seems as though the ProxyTo doesn't have any trouble with http://host:12345 and the automatic mappings with the same host:port. The ProxyRewrite on the other hand doesn't work with host:port. It's as if the pattern matching goes out to lunch, gets amnesia.. something. I've also noticed that if I have multiple ProxyRewrite statements the last one (provide there's no port number) is the only one being processed. Thanks! Dwayne * * Dwayne Turley, Sr. System Administrator, Code 589 (Wallops) * Real Time Software Engineering Branch * Building N161, Wallops Island VA 23337 * Phone: 757 824 1135 Fax: 757 824 1903 * mailto:[EMAIL PROTECTED] * We all know Linux is great...it does infinite loops in 5 seconds. -- Linus Windows: Where do you want to go today? MacOS: Where do you want to be tomorrow? Linux: Are you coming or what? Windows is not the answer. Windows is the question. No, is the answer.
Re: Module caching
Scott [EMAIL PROTECTED] writes: Hello all, I am working on a large modperl app, and one of the features of this is a plugin system that allows others to write and install modules. Everything is good as far as this goes, but the problem is updateing/deleting modules. It seems as though the code is cached until an apache restart (i.e code changes don't take effect, version numbers don't change). Is there a way to flush the INC hash of all the children programmatically, without a restart? I have looked at Apache::Reload and Apache::StatINC and tried to replicate the code, but it doesn't seem to be working. The best thing I happened to meet here: - apache compiled with mod_perl as DSO (for instance debian linux version) - graceful restart which is invisible for the clients but reloads perl interpreter when mod_perl is DSO
Re: need your help to test mod_perl with perl-5.8.1-RC3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Well, now that I've had a day or so to play with it (using both worker and prefork), I have yet to see any issues. It looks good. However, any further testing I do will probably be limited to prefork, since the overhead of ithreads manages to eat all the memory on my workstation. - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer/DBE, Core Technology Developer The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE/KuSoA4aoazQ9p2cRAiDAAKDxbLR17B4R/2w8tD56aKTcKlQ8EgCgo8B0 ICKCbkeKlf6Xe/WE7bwlpm8= =C6/k -END PGP SIGNATURE-
Apache::AuthCookie 3.05 prerelease
I have placed a pre-release of Apache::AuthCookie 3.05 which supports mod_perl version 2 (as well as mod_perl version 1) up on the sorceforge downloads. The API has changed slightly for mod_perl version 2 in order to avoid using Apache-request. See the README.modperl2 file in the distribution for the detailed changes. The API has not changed in the version of the module for mod_perl 1.x. Obviously since the API has changed, and because this is the first release supporting mod_perl v2, this is an alpha release. This release is targeted at developers of AuthCookie subclasses that wish to port their subclasses to mod_perl2. If I do not get complaints about the AuthCookie API changes that I have made, I will upload this release to CPAN. You can get AuthCookie 3.05pre1 from: https://sourceforge.net/project/showfiles.php?group_id=12701 Regards, Michael Schout GKG.NET, INC
Re: need your help to test mod_perl with perl-5.8.1-RC3
On Fri, Aug 01, 2003 at 09:05:55AM +0100, Steve Hay wrote: 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. Oh yeah, I didn't update the snapshot. Thanks for the reminder. -- You can't control the universe with a jar of red pepper. http://www.goats.com/archive/981004.html
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: Skipped Tests (was: handler help)
I am still here, trying to build mod_perl 2. Many thanks to everyone who offered help. To recap: I freshly installed RedHat 9 on a box, then used RPM to remove modules involving httpd. (See notes below). Then I built perl 5.8.0 from source, first doing a export LANG=C to address the UTF bug. The perl build worked. I did everything as non-root until the make install, which I did as root. I then built Apache 2.0.47 from source. Seemed to go OK (there was no make test step...) I did everything as non-root until the make install, which I did as root. Then as root I used CPAN to install Bundle::WWW, LWP, and HTML::Parser. Had some troubles, used the force option, and plowed ahead. (Maybe I should have stopped here at the first sign of trouble) As non-root, did cd mod_perl-1.99_09/ perl Makefile.PL MP_AP_PREFIX=$HOME/httpd/prefork MP_INST_APACHE2=1 make which went fine. make tests did not work -- below is the bottom of the output. Argh! Suggestions? - A PS Below the make test output below, I included a note file where I've been pasting commands I've run... in some places, it contains notes, rather than exact linux commands. == = BOTTOM OF FAILED make test == snip /usr/bin/perl -Iblib/arch/Apache2 -Iblib/lib/Apache2 \ t/TEST -clean *** setting ulimit to allow core files ulimit -c unlimited; t/TEST -clean APACHE_USER= APACHE_GROUP= APACHE_PORT= APACHE= APXS= \ /usr/bin/perl -Iblib/arch/Apache2 -Iblib/lib/Apache2 \ t/TEST -verbose=0 *** setting ulimit to allow core files ulimit -c unlimited; t/TEST -verbose=0 /home/aprk/httpd/prefork/bin/httpd -d /home/aprk/src/mod_perl-1.99_09/t -f /home/aprk/src/mod_perl-1.99_09/t/conf/httpd.conf -DAPACHE2 using Apache/2.0.47 (prefork MPM) waiting for server to start: ..[Fri Aug 01 22:34:36 2003] [info] 19 Apache:: modules loaded [Fri Aug 01 22:34:36 2003] [info] 3 APR:: modules loaded [Fri Aug 01 22:34:36 2003] [info] base server + 8 vhosts ready to run tests .. waiting for server to start: ok (waited 2 secs) server SAM:8529 started server SAM:8530 listening (TestProtocol::echo_filter) server SAM:8531 listening (TestProtocol::echo) server SAM:8532 listening (TestPreConnection::note) server SAM:8533 listening (TestFilter::in_str_msg) server SAM:8534 listening (TestFilter__both_str_con_add) server SAM:8535 listening (TestFilter::in_bbs_msg) server SAM:8536 listening (TestDirective::perlmodule) server SAM:8537 listening (TestDirective::perlrequire) server SAM:8538 listening (TestDirective::perlloadmodule4) server SAM:8539 listening (TestDirective::perlloadmodule5) server SAM:8540 listening (TestDirective::perlloadmodule3) server SAM:8541 listening (TestDirective::perlloadmodule6) apache/add_config..ok apache/cgihandler..ok apache/conftreeok apache/constants...ok apache/postok apache/readok apache/scanhdrsok apache/scanhdrs2...ok apache/send_cgi_header.ok apache/subprocess..ok apache/write...ok api/access.ok api/aplog..ok api/conn_rec...ok api/lookup_uri.ok api/lookup_uri2ok api/module.ok api/r_subclass.ok api/request_recok api/response...ok api/rutil..ok api/sendfile...ok api/server_rec.ok api/server_utilok api/uriok apr/base64.ok apr/constants..ok apr/date...ok apr/netlib.ok apr/os.ok apr/pool...ok apr/socket.ok apr/string.ok apr/table..ok apr/threadmutexskipped all skipped: Perl was not built with 'ithreads' enabled apr/util...ok apr/uuid...ok compat/apache..ok compat/apache_file.ok compat/apache_tableok compat/apache_uri..ok compat/apache_util.ok compat/conn_authen.ok compat/request.ok compat/request_bodyok compat/send_fd.ok directive/env..ok directive/perl.ok directive/perldo...ok directive/perlloadmodule...ok directive/perlloadmodule2..ok directive/perlloadmodule3..ok directive/perlloadmodule4..ok directive/perlloadmodule5..ok directive/perlloadmodule6..ok directive/perlmodule...ok directive/perlrequire..ok directive/pod..ok directive/setupenv.ok error/api..ok error/runtime..ok error/syntax...ok filter/both_str_con_addok filter/both_str_req_addok
Re: need your help to test mod_perl with perl-5.8.1-RC3
On Fri, Aug 01, 2003 at 11:35:47AM +0100, Steve Hay wrote:
=
# --- 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?
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.
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.
It would be nice if someone could dig through libapreq's version history
and figure out when and why this hack was put in.
--
WOOHOO! I'm going to Disneyland!
http://www.goats.com/archive/980805.html
Re: Skipped Tests (was: handler help)
Hi there, On Fri, 1 Aug 2003, Tofu Optimist wrote: Exactly HOW do I change the locale? http://twiki.org/cgi-bin/view/Codev/UsingPerl58OnRedHat8 about half a dozen messages down. See also http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=87682 make make install again, yes? Better start with % cd /home/directory/src (or whatever your home directory is) and then % rm -rf apache_1.3.28 % rm -rf mod_perl-1.28 % tar xzvf apache_1.3.28.tgz % tar xzvf mod_perl-1.28 % perl Makefile.PL and I would suggest that in future instead of % make make install that you do these steps as separate commands % make % make test % su Password: # make install # exit % which will give you the opportunity to abandon ship at any point before the install. Finally if you do % script before you start the 'perl Makefile.PL' step then everything you see on the screen will be logged to a file so you can peruse it later if you feel the need. It will help you to become familiar with build the process. It looks a lot more complicated than it is. Really. % man script for more details. I'd use 'less -S' to look at the scriptfile. In fact I always alias 'less -S' to 'li' in my login scripts... :) 73, Ged.
Re: Skipped Tests (was: handler help)
Hello again, On Fri, 1 Aug 2003, Tofu Optimist wrote: To recap: I freshly installed RedHat 9 on a box, then used RPM to remove modules involving httpd. (See notes below). Then I built perl 5.8.0 from source, first doing a export LANG=C why not LANG=en_US ? Then as root I used CPAN to install Bundle::WWW, LWP, and HTML::Parser. Had some troubles, used the force option, Oooohhh. Don't do that... We're getting out of my area of experience here, I don't use mod_perl2, but I hear there are recent changes to CGI.pm. Did you install the latest CGI.pm? You should. 73, Ged.
