[mp1] Can´t compile mp1.28 - worked with 1.27
Hi, I am trying to compile mod_perl-1.28 without luck. Here is my config: SUSE 5.3 (I know it´s old) gcc -v Reading specs from /usr/lib/gcc-lib/i486-linux/2.7.2.1/specs gcc version 2.7.2.1 Perl-5.8.0, Apache-1.3.28 mod_perl-1.28 from source. perl Makefile.PL APACHE_SRC=/develop/apache_1.3.28/src NO_HTTPD=1 \ USE_APACI=1 PREP_HTTPD=1 EVERYTHING=1 SSL_BASE=/usr \ ./configure --prefix=/usr/local/apache \ --enable-module=rewrite --enable-shared=rewrite \ --enable-module=speling --enable-shared=speling \ --enable-module=expires --enable-shared=expires \ --enable-module=info--enable-shared=info \ --enable-module=log_agent --enable-shared=log_agent \ --enable-module=log_referer --enable-shared=log_referer \ --enable-module=usertrack --enable-shared=usertrack \ --enable-module=proxy --enable-shared=proxy \ --enable-module=userdir --enable-shared=userdir \ --enable-shared=ssl --enable-module=ssl \ --activate-module=src/modules/perl/libperl.a --enable-shared=perl \ --enable-module=so --enable-suexec \ --suexec-caller=www --suexec-docroot=/usr/local/apache\ --suexec-logfile=apache_suexec_log --sysconfdir=/etc/apache \ --localstatedir=/etc/apache --runtimedir=/etc/apache \ --logfiledir=/etc/apache gives this: + mod_perl build type: DSO + id: mod_perl/1.28 + id: Perl/v5.8.0 (linux) [perl] + setting up mod_perl build environment + adjusting Apache build environment ** Error: Cannot build mod_include with Perl support (USE_PERL_SSI) ** ** when mod_perl is compiled as DSO because of cross-module calls. ** ** Ignoring PERL_SSI flag now. ** With Apache-1.3.27 and mod_perl-1.27 I could compile using the same Perl-installation. Compiling mod_perl static into httpd gives errors when compiling. They are described here: http://thingy.kcilink.com/modperlguide/install/Undefined_reference_to_P erl_new.html I even tried a new Perl directory from source but got the same error. With 1.27 it worked with DSO, what has changed? Here are Perl infos from the newly compiled version for which I used the same Policy.SH and config.sh: perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=linux, osvers=2.0.35, archname=i686-linux uname='linux bernd-vmware 2.0.35 #10 wed aug 19 12:01:26 mest 1998 i686 unknown ' config_args='-d' hint=previous, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-I/usr/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-I/usr/include -I/usr/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 -I/usr/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 -I/usr/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 -I/usr/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 -I/usr/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64' ccversion='', gccversion='2.7.2.1', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags ='-L/usr/lib -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lgdbm -ldbm -ldb -ldl -lm -lc -lpoll perllibs=-ldl -lm -lc -lpoll libc=/lib/libc.so.5.4.46, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='- rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/lib -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under linux Compiled at Aug 27 2003 13:57:03 @INC: /usr/local/perl/lib /usr/local/perl/lib /usr/local/perl/lib /usr/local/perl/lib . For all programs I used the same compiler and as I stated with the earlier versions compiling never was a problem. Maybe I am missing something easy but I looked around for two days now, read this newsgroup and used Google so any help is very appreciated. Greetings, Bernd -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
=?x-unknown?q?Re=3A_=5Bmp1=5D_Can=B4t_compile_mp1=2E28_-_work?==?x-unknown?q?ed_with_1=2E27?=
Hi there, On Wed, 27 Aug 2003, Bernd Kuhls wrote: I am trying to compile mod_perl-1.28 without luck. SUSE 5.3 (I know it´s old) gcc version 2.7.2.1 =:0 Perl-5.8.0, Apache-1.3.28 mod_perl-1.28 from source. With Apache-1.3.27 and mod_perl-1.27 I could compile using the same Perl-installation. You mean using Perl 5.8.0? ** Error: Cannot build mod_include with Perl support (USE_PERL_SSI) ** ** when mod_perl is compiled as DSO because of cross-module calls. ** ** Ignoring PERL_SSI flag now. ** Have you tried it without EVERYTHING=1? With 1.27 it worked with DSO, what has changed? Er, have you checked the CHANGELOG? Compiler: cc='cc', ccflags ='-I/usr/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-I/usr/include -I/usr/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 -I/usr/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 -I/usr/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 -I/usr/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64 -I/usr/include -D_LARGEFILE_SOURCE - D_FILE_OFFSET_BITS=64' This doesn't look good at all. Try without LARGEFILE support? osname=linux, osvers=2.0.35, archname=i686-linux Does that say 2.0.35 or do I need new glasses? For all programs I used the same compiler and as I stated with the earlier versions compiling never was a problem. I'm surprised you got away with it for so long really. Your OS and compiler are very old. What version of the C libraries are you using? The link you mentioned does say that the error you get when building static is a symptom of a broken Perl. Did you run the Perl testsuite when you built your Perl, and if so what failed? 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: perl.apache.org problem
Quoting Stas Bekman [EMAIL PROTECTED]: Cees Hek wrote: It looks like something has gone awry with the perl.apache.org website. It is currently pointing to the Apache Portable Runtime website. You can bypass it by going directly to: http://perl.apache.org/index2.html This looks like the result of a change to put up a protest page at the start of every *.apache.org website. Perhaps someone can notify the powers that be to fix the problem. There is no problem, Cees. This is done by the Apache Software Foundation. mod_perl is an ASF project if you didn't know. Have you read what it says on http://perl.apache.org/? Hi Stas, The protest page wasn't the problem. I did noticed that they had put it on all the .apache.org websites. However when I went to perl.apache.org, instead of seeing the protest page or the mod_perl website, I got the Apache Portable Runtime website (ie the page found at http://apr.apache.org). I guess the admins at the Apache Foundation noticed quickly enough and fixed the problem. Cheers, Cees -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: =?x-unknown?q?Re=3A_=5Bmp1=5D_Can=B4t_compile_mp1=2E28_-_work?==?x-unknown?q?ed_with_1=2E27?=
Hi, On Do 28 Aug 2003 01:59:14a Ged Haywood wrote: Have you tried it without EVERYTHING=1? *that* did the trick, thank you! [Wed Aug 27 17:22:32 2003] [notice] Apache/1.3.28 (Unix) mod_perl/1.28 PHP/4.3.3 mod_ssl/2.8.15 OpenSSL/0.9.7b configured -- resuming normal operations osname=linux, osvers=2.0.35, archname=i686-linux Does that say 2.0.35 or do I need new glasses? Your eyes and glasses are ok;-) I need Apache for a very old system for historical reasons. I'm surprised you got away with it for so long really. Your OS and compiler are very old. What version of the C libraries are you using? Libc.5.4.46;-) And it is working..., yet. Greetings, Bernd -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Ticket/cookie based authentication for mod_perl and static frontend
Good afternoon, On 27/8/03 at 9:37 AM -0400, Michael [EMAIL PROTECTED] wrote: The reason this question is mod_perl related is that he is doing the initial authentication using mod_perl, and is creating a cookie based ticket. But he wants that ticket to also be accepted by a non-mod_perl enabled server (ie a front end proxy). So the database connection has to persist from the mod_perl authentication scheme to the backend software? Interesting... Does that work? This isn't really an issue with database connections. It's just the authentication data/method that needs to persist for both. And that is handled by a cookie/ticket authentication. Thanks to Cees Hek [EMAIL PROTECTED] for helping me find a module I had lost track of. The module is mod_auth_tkt and can be found here: http://www.openfusion.com.au/labs/mod_auth_tkt/ I'm on my way to having an elegant solution now. Thanks to all who responded. Charlie -- Charlie Garrison[EMAIL PROTECTED] PO Box 141, Windsor, NSW 2756, Australia -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Ticket/cookie based authentication for mod_perl and static frontend
Good afternoon, On 27/8/03 at 9:45 AM -0400, Michael [EMAIL PROTECTED] wrote: Any other suggestions? I'd think you'd want to have the same authentication process for both, and a shared database (or something) to store the session data. Have the front-end do the login part, pass the client to the backend, which discovers that the client is already authenticated. Using tickets for authentication will work with both the front and backend servers. I was having problems finding a solution which had an apache module (written in C) plus support/examples for perl to use in the backend. With thanks to Cees Hek [EMAIL PROTECTED] I found mod_auth_tkt which does just what I need. Charlie -- Charlie Garrison[EMAIL PROTECTED] PO Box 141, Windsor, NSW 2756, Australia -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::DBI not really loading
I've set Apache::DBI::DEBUG to 2, and I'm not seeing _any_ messages (from it) in the error log. Apache::Status lists Apache DBI, but lists no database connections. A long time ago, one problem used to be that if your connect to Postgres was idle for too long ( 8 hours ) the connection would timeout and give you these kinds of errors. One solution was to make sure that you hit a web page that has such a connection periodically, 1) Wasn't this problem corrected by using the ping() method? 2) I'm hoping for a clue why Apache::DBI is there but not giving any messages or having any connections in Apache::Status 3) Avoiding timeout doesn't help when the network hiccups and drops existing connections (I don't admin the network, can't change that) This may not be related to your current problem, so YMMV. Doesn't appear helpful, but I appreciate some response :) -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp1] consistent segfaults with HTML::Mason
Stephen [EMAIL PROTECTED] wrote:
I'm no expert at debugging C, but I dont think that the above looks too
healthy
Well, I think I have it figured out, more or less. The root cause of it
seemed to be a rather, um, interesting bit of code in
HTML::Mason::ApacheHandler which makes use of string eval and sprintf to
define the handler() subroutine. The intent was to create a handler()
routine suitable for both mod_perl 1 and 2 (prototype of ($$) vs attribute
of : method). However, for some reason or another, handler() was being
called as a regular sub, with one parameter.
Preloading the module and using the explicit Module-handler method syntax
in httpd.conf seems to have fixed it. (Having said that, it seems to be
working without the additional -handler now ... *sighs*. Either I failed
to add method handlers to the config before, or I'm collecting on a karmic
debt. Or both).
As for the segfaults, I patched my mod_perl source to return undef in that
situation as opposed to segfault, which seems slightly more reasonable
behaviour. Patch below:
--- src/modules/perl/Apache.xs-origFri Jun 6 12:31:10 2003
+++ src/modules/perl/Apache.xs Thu Aug 28 12:10:53 2003
@@ -2075,7 +2075,10 @@
SvREFCNT_dec(RETVAL); /* in case above did newSV(0) */
cs = (perl_server_config *)get_module_config(s-module_config,
perl_module);
- TABLE_GET_SET(cs-vars, FALSE);
+if(cs) {
+ TABLE_GET_SET(cs-vars, FALSE);
+}
+else XSRETURN_UNDEF;
}
else XSRETURN_UNDEF;
}
This has taught me more about XS and the um, interesting capabilities of
string eval than I ever wanted to know, I think. Please excuse me whilst I
take a cold shower or three...
Stephen Veiss
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp1] consistent segfaults with HTML::Mason
Stephen wrote:
[...]
The intent was to create a handler()
routine suitable for both mod_perl 1 and 2 (prototype of ($$) vs attribute
of : method). However, for some reason or another, handler() was being
called as a regular sub, with one parameter.
I have used the technique documented here:
http://perl.apache.org/docs/2.0/user/porting/porting.html#Method_Handlers
which in short words comes to:
sub handler_mp1 ($$) { mp1 }
sub handler_mp2 : method { mp2 }
*handler = MP2 ? \handler_mp2 : \handler_mp1;
One thing I forgot to mention, is that : method won't work with perl 5.6.
So if you can share your solution, I'd it to that section.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
[mp2] make test failed
Hello! 1. Problem Description: Errors while 'make test' was in filter/in_bbs_msg.t and hooks/trans.t so output of make test TEST_VERBOSE=1 TEST_FILES=filter/in_bbs_msg.t hooks/trans.t is: filter/in_bbs_msg# connecting to www.myhost.ru:8535 server side has failed (response code: 404), see t/logs/error_log for more details dubious Test returned status 29 (wstat 7424, 0x1d00) hooks/trans..1..3 ok 1 Use of uninitialized value in pattern match (m//) at hooks/trans.t line 20. dubious Test returned status 29 (wstat 7424, 0x1d00) DIED. FAILED tests 2-3 Failed 2/3 tests, 33.33% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- filter/in_bbs_msg.t 29 7424?? ?? % ?? hooks/trans.t 29 7424 32 66.67% 2-3 -- Content of t/logs/error_log: [Thu Aug 28 20:34:10 2003] [info] mod_unique_id: using ip addr 127.0.0.1 END in modperl_extra.pl, pid=18558 [Thu Aug 28 20:34:11 2003] [notice] Digest: generating secret for digest authentication ... [Thu Aug 28 20:34:18 2003] [notice] Digest: done [Thu Aug 28 20:34:18 2003] [info] mod_unique_id: using ip addr 127.0.0.1 [Thu Aug 28 20:34:19 2003] [notice] Apache/2.0.47 (Unix) mod_perl/1.99_09 Perl/v5.8.0 DAV/2 configured -- resuming normal ope rations [Thu Aug 28 20:34:19 2003] [info] Server built: Aug 28 2003 18:59:50 [Thu Aug 28 20:34:19 2003] [debug] prefork.c(1037): AcceptMutex: sysvsem (default: sysvsem) [Thu Aug 28 20:34:19 2003] [info] (22)Invalid argument: core_output_filter: writing data to the network [Thu Aug 28 20:34:19 2003] [error] [client 127.0.0.1] File does not exist: /usr/src/httpd_perl/mod_perl-1.99_09/t/htdocs/inpu t_filter.html *** The following error entry is expected and it is harmless *** [Thu Aug 28 20:34:20 2003] [error] server reached MaxClients setting, consider raising the MaxClients setting [Thu Aug 28 20:34:20 2003] [error] [client 127.0.0.1] File does not exist: /usr/src/httpd_perl/mod_perl-1.99_09/t/htdocs/nope [Thu Aug 28 20:34:20 2003] [info] (22)Invalid argument: core_output_filter: writing data to the network [Thu Aug 28 20:34:20 2003] [info] Child process pid=18617 is exiting [Thu Aug 28 20:34:20 2003] [info] removed PID file /usr/src/httpd_perl/mod_perl-1.99_09/t/logs/httpd.pid (pid=18565) [Thu Aug 28 20:34:20 2003] [notice] caught SIGTERM, shutting down END in modperl_extra.pl, pid=18565 2. Used Components and their Configuration: *** using lib/Apache/BuildConfig.pm *** Makefile.PL options: MP_AP_PREFIX= /usr/local/httpd_perl MP_COMPAT_1X= 1 MP_GENERATE_XS = 1 MP_INST_APACHE2 = 1 MP_LIBNAME = mod_perl MP_USE_DSO = 1 MP_USE_STATIC = 1 *** /usr/local/httpd_perl/bin/httpd -V Server version: Apache/2.0.47 Server built: Aug 28 2003 18:59:50 Server's Module Magic Number: 20020903:4 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR=server/mpm/prefork -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT=/usr/local/httpd_perl -D SUEXEC_BIN=/usr/local/httpd_perl/bin/suexec -D DEFAULT_PIDLOG=logs/httpd.pid -D DEFAULT_SCOREBOARD=logs/apache_runtime_status -D DEFAULT_LOCKFILE=logs/accept.lock -D DEFAULT_ERRORLOG=logs/error_log -D AP_TYPES_CONFIG_FILE=conf/mime.types -D SERVER_CONFIG_FILE=conf/httpd.conf *** /usr/local/bin/perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=linux, osvers=2.4.1-008stab044.8.swsoft-smp, archname=i686-linux uname='linux www.webstores.ru 2.4.1-008stab044.8.swsoft-smp #1 smp fri jun 6 18:26:06 msd 2003 i686 unknown ' config_args='-de' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gd bm', optimize='-O2', cppflags='-fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm' ccversion='', gccversion='2.96 2731 (ASPLinux 7.1 2.96-85.asp)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lndbm -lgdbm -ldl -lm -lc -lcrypt -lutil perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil
Re: [mp1] consistent segfaults with HTML::Mason
Stephen wrote: Stephen [EMAIL PROTECTED] wrote: I'm no expert at debugging C, but I dont think that the above looks too healthy Well, I think I have it figured out, more or less. The root cause of it seemed to be a rather, um, interesting bit of code in HTML::Mason::ApacheHandler which makes use of string eval and sprintf to define the handler() subroutine. The intent was to create a handler() routine suitable for both mod_perl 1 and 2 (prototype of ($$) vs attribute of : method). However, for some reason or another, handler() was being called as a regular sub, with one parameter. mp1 supports both $$ and :method, so no need to do something special to make it work for both mp1 and mp2. Preloading the module and using the explicit Module-handler method syntax in httpd.conf seems to have fixed it. preloading is required in mp1. the - syntax is not. HTH --Geoff -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] make test failed
Alan Rafagudinov wrote: Hello! 1. Problem Description: Thanks for the detailed report, Alan. Errors while 'make test' was in filter/in_bbs_msg.t and hooks/trans.t [Thu Aug 28 20:34:19 2003] [info] (22)Invalid argument: core_output_filter: writing data to the network [Thu Aug 28 20:34:19 2003] [error] [client 127.0.0.1] File does not exist: /usr/src/httpd_perl/mod_perl-1.99_09/t/htdocs/inpu t_filter.html [...] *** /usr/local/httpd_perl/bin/httpd -V Server version: Apache/2.0.47 Server built: Aug 28 2003 18:59:50 Server's Module Magic Number: 20020903:4 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR=server/mpm/prefork -D APR_HAS_SENDFILE My guess is that you've been hit by this Apache problem: http://httpd.apache.org/docs-2.0/faq/error.html#error.sendfile As the URL above suggests, try to add 'EnableSendfile On' somewhere in t/conf/httpd.conf and rerun: t/TEST -v filter/in_bbs_msg.t hooks/trans.t don't run 'make test' as it'll rewrite t/conf/httpd.conf, use t/TEST instead. I wonder why http://httpd.apache.org/docs-2.0/mod/core.html#enablesendfile says that it's on by default. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] make test failed
My guess is that you've been hit by this Apache problem: http://httpd.apache.org/docs-2.0/faq/error.html#error.sendfile As the URL above suggests, try to add 'EnableSendfile On' somewhere in t/conf/httpd.conf and rerun: t/TEST -v filter/in_bbs_msg.t hooks/trans.t don't run 'make test' as it'll rewrite t/conf/httpd.conf, use t/TEST instead. I wonder why http://httpd.apache.org/docs-2.0/mod/core.html#enablesendfile says that it's on by default. Argh, I confused simply use the EnableSendfile directive as to be turned on. It should be: EnableSendfile Off of course. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Offtopic: CGI.pm and mixing post/get
I know this off topic, but somewhat close. ;-) Is there an easy way to use the param function in CGI.pm with mixed POST and GET data? I have some pages that use both (GET to the area, w/a form submision, for example) and it seems CGIs param will only get one type at a time. It seems POST overrides GET, which I'd agree w/if the param names where the same, but not if different. I've done mixed in the past w/PHP. Anyway, you guys seem to be likely candidates to answer this one, so I am asking. Please go off list if you feel it isn't modperl related. Thanks -Bruce www.bluewolverine.com Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software
Modules Problem
I in the process of switching my scripts over to Mod Perl.
I decide since Mod Perl doesn't like Sub routine in the the main program I'd
export make Modules out of the more come ones. Simple process I thought.
However no mater what I do I get an error. I tried making a simple one using
the example code from the site and failed stil.
Error:
Undefined subroutine main::CISCHeader called at /var/www/perl/test.pl line
5.
Here the Module Located in the ModPerl Directory under the a directory
listed int eh @inc:
package ModPerl::Rules1;
sub CISCHeader {
print Content-type: text/plain\n\n;
print mod_perl rules!\n;
return 1;
}
1;
The Script:
#!/usr/bin/perl -w
use strict;
use ModPerl::Rules1;
CISCHeader();
I'm Stumpped and would love some advise or suggestions.
_
Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige
using MSN Messenger http://entertainment.msn.com/imastar
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Modules Problem
You need to setup exports in your Rules1 package.
Take a look at Exporter. (perldoc Exporter)
OR, call the function with its fully qualified package nameTim Edwards [EMAIL PROTECTED] wrote:
I in the process of switching my scripts over to Mod Perl.I decide since Mod Perl doesn't like Sub routine in the the main program I'd export make Modules out of the more come ones. Simple process I thought. However no mater what I do I get an error. I tried making a simple one using the example code from the site and failed stil.Error:Undefined subroutine main::CISCHeader called at /var/www/perl/test.pl line 5.Here the Module Located in the ModPerl Directory under the a directory listed int eh @inc:package ModPerl::Rules1;sub CISCHeader {print "Content-type: text/plain\n\n";print "mod_perl rules!\n";return 1;}1;The Script:#!/usr/bin/perl -wuse strict;use ModPerl::Rules1;CISCHeader();I'm Stumpped and would love some advise or
suggestions._Enter for your chance to IM with Bon Jovi, Seal, Bow Wow, or Mary J Blige using MSN Messenger http://entertainment.msn.com/imastar-- Reporting bugs: http://perl.apache.org/bugs/Mail list info: http://perl.apache.org/maillist/modperl.htmlwww.bluewolverine.com
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
Apache::Test unable to locate libperl.so?
Title: Apache::Test unable to locate libperl.so?
I'm trying to come up to speed on Apache::Test. I'm working from Stas's documentation at http://perl.apache.org/docs/general/testing/testing.html. My system is roughly:
gentoo linux 1.4
perl 5.8.0 useithreads=undef useperlio=define
apache 1.3.28
mod_perl 1.3.28
Apache::Test 1.04 (2003/08/28 cvs snapshot)
I ended up having to patch TestConfig.pm so that it could locate libperl.so. TestConfig.pm's find_apache_module method doesn't try the /usr/lib/apache-extramodules directory... Which is where Gentoo linux likes to put it. A few searches on google suggest Mandrake may put things there as well.
I don't know the story on extramodules... If anyone is familiar with it please point me to any documentation or rational on why it exists and what advantage it offers. I hate finding customizations without a clue as to why they're there.
Anyways what follows is my best guess on a reasonable way to locate it when trying to find modules.
--- /home/ggoebel/src/mp2/modperl-2.0/Apache-Test/lib/Apache/TestConfig.pm
2003-08-13 17:15:38.0 -0500
+++ TestConfig.pm 2003-08-28 15:17:52.0 -0500
@@ -637,6 +637,7 @@
my @trys = grep { $_ }
($vars-{src_dir},
$self-apxs('LIBEXECDIR'),
+ $self-apxs('LIBEXECDIR').'-extramodules',
catfile($sroot, 'modules'),
catfile($sroot, 'libexec'));
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com garrett at scriptpro dot com
testconfig.pm.patch
Description: Binary data
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Modules Problem
On Thu, 2003-08-28 at 16:09, Tim Edwards wrote:
I in the process of switching my scripts over to Mod Perl.
I decide since Mod Perl doesn't like Sub routine in the the main program I'd
export make Modules out of the more come ones.
Just to be clear, mod_perl has no problem with subroutines inside of the
main program. Apache::Registry has issues with it but only if you are
using lexically scoped variables and declaring them outside of your subs
rather than passing all parameters to the subs.
In other words, don't do this with Apache::Registry:
my $cgi = CGI-new();
foo();
sub foo {
my $input = $cgi-param('input');
}
That breaks because $cgi is not passed to foo(), so it becomes a closure
and will always be the same as it was the first time the script was run.
Error:
Undefined subroutine main::CISCHeader called at /var/www/perl/test.pl line
5.
Here the Module Located in the ModPerl Directory under the a directory
listed int eh @inc:
package ModPerl::Rules1;
sub CISCHeader {
print Content-type: text/plain\n\n;
print mod_perl rules!\n;
return 1;
}
1;
The Script:
#!/usr/bin/perl -w
use strict;
use ModPerl::Rules1;
CISCHeader();
Your module doesn't export the CISCHeader sub, so you have to call it
with the full name: ModPerl::Rules1::CISCHeader(). If this doesn't make
sense to you, you should read the perlmod man page that explains how
modules and packages work.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp1] consistent segfaults with HTML::Mason
Geoffrey Young wrote: mp1 supports both $$ and :method, so no need to do something special to make it work for both mp1 and mp2. Aah, I'll pass that onto the Mason folks. Ta. Preloading the module and using the explicit Module-handler method syntax in httpd.conf seems to have fixed it. preloading is required in mp1. the - syntax is not. Ah, looks like that was it, in that case. Stephen Veiss -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Source for Apache::Test documentation on perl.apache.org
Title: Source for Apache::Test documentation on perl.apache.org As I stated in a previous post, I'm coming up to speed on Apache::Test by working from Stas's documentation at http://perl.apache.org/docs/general/testing/testing.html. I remember seeing a few typos on my first pass through the documentation. Now that I've got a simple perl Makefile.PL make make test make install Working with Apache::Test support, I thought I'd go back through the docs with more of an eye to detail. When I run past those typos again, I'd like to be able to submit patches and ask questions. So... Is the source for that document publically available? and What would be most appropriate: post patches and questions here, to Stas directly, or somewhere else? -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com garrett at scriptpro dot com
Re: Source for Apache::Test documentation on perl.apache.org
Garrett Goebel wrote: As I stated in a previous post, I'm coming up to speed on Apache::Test by working from Stas's documentation at http://perl.apache.org/docs/general/testing/testing.html. I remember seeing a few typos on my first pass through the documentation. Now that I've got a simple perl Makefile.PL make make test make install Working with Apache::Test support, I thought I'd go back through the docs with more of an eye to detail. When I run past those typos again, I'd like to be able to submit patches and ask questions. So... Is the source for that document publically available? Yes, there is a documentation repository that you can checkout and get patches against the cvs. See: http://perl.apache.org/download/docs.html that file would be in src/docs/general/testing/testing.pod We also need to improve the Apache-Test manpages, besides the tutorial, so if you do any additions/fixes there, you will need to use the modperl-2.0 cvs repository, available from here: http://perl.apache.org/download/source.html#Development_mod_perl_2_0_Source_Distribution and What would be most appropriate: post patches and questions here, to Stas directly, or somewhere else? Please, post them to the dev list: http://perl.apache.org/maillist/dev.html __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Test unable to locate libperl.so?
Garrett Goebel wrote:
I'm trying to come up to speed on Apache::Test. I'm working from Stas's
documentation at
http://perl.apache.org/docs/general/testing/testing.html. My system is
roughly:
gentoo linux 1.4
perl 5.8.0 useithreads=undef useperlio=define
apache 1.3.28
mod_perl 1.3.28
Apache::Test 1.04 (2003/08/28 cvs snapshot)
I ended up having to patch TestConfig.pm so that it could locate
libperl.so. TestConfig.pm's find_apache_module method doesn't try the
/usr/lib/apache-extramodules directory... Which is where Gentoo linux
likes to put it. A few searches on google suggest Mandrake may put
things there as well.
I don't know the story on extramodules... If anyone is familiar with
it please point me to any documentation or rational on why it exists and
what advantage it offers. I hate finding customizations without a clue
as to why they're there.
If a distro changes the default LIBEXECDIR after building apache, (and not
during ./configure) it has to fix apxs to report the new value, so that 'apxs
-q LIBEXECDIR' gets the right value. If it doesn't please report a bug to the
distro maintainers and ask them them fix that package.
Sorry, but I don't think this approach of adjusting to each distro's will
going to work. We already do too much guess-work that I'm thinking of
dropping, since it does more evil than goodness.
Meanwhile symlinking libexec-extramodules = libexec should do the trick.
Anyways what follows is my best guess on a reasonable way to locate it
when trying to find modules.
--- /home/ggoebel/src/mp2/modperl-2.0/Apache-Test/lib/Apache/TestConfig.pm
2003-08-13 17:15:38.0 -0500
+++ TestConfig.pm 2003-08-28 15:17:52.0 -0500
@@ -637,6 +637,7 @@
my @trys = grep { $_ }
($vars-{src_dir},
$self-apxs('LIBEXECDIR'),
+ $self-apxs('LIBEXECDIR').'-extramodules',
catfile($sroot, 'modules'),
catfile($sroot, 'libexec'));
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
