cvs commit: modperl-2.0 Changes
stas2003/01/15 18:38:09 Modified:.Changes Log: log the recent changes Revision ChangesPath 1.101 +14 -2 modperl-2.0/Changes Index: Changes === RCS file: /home/cvs/modperl-2.0/Changes,v retrieving revision 1.100 retrieving revision 1.101 diff -u -r1.100 -r1.101 --- Changes 14 Jan 2003 06:42:44 - 1.100 +++ Changes 16 Jan 2003 02:38:09 - 1.101 @@ -10,9 +10,21 @@ =item 1.99_09-dev -prevent a segfault when push_handlers are used to push a handler into -the currently phase and switching the handler (perl-script/modperl) +input stream filtering support was added + tests (plus renaming filter +tests so we can know from the test name what kind of filter is tested) [Stas] + +Add proper support for mis-behaved feeding filters that send more than +one EOS bucket in streaming filters + test. [Stas] + +implement a more robust autogenerated client .t test in +Apache::TestConfigPerl. Before this fix if the server side returned +500, the test would get skipped, not good. Now it will die a horrible +death. [Stas] + +prevent a segfault when push_handlers are used to push a handler into +the currently phase and switching the handler (perl-script/modperl) + +tests [Stas] Add $filter-seen_eos to the streaming filter api to know when eos has been seen, so special signatures can be passed and any data stored in
cvs commit: modperl-2.0/t/filter/TestFilter in_str_consume.pm
stas2003/01/15 21:15:18
Added: t/filter in_str_consume.t
t/filter/TestFilter in_str_consume.pm
Log:
add a faulty filter test, but keep the fault disabled for now
Revision ChangesPath
1.1 modperl-2.0/t/filter/in_str_consume.t
Index: in_str_consume.t
===
use strict;
use warnings FATAL = 'all';
use Apache::Test;
use Apache::TestUtil;
use Apache::TestRequest;
plan tests = 1;
my $location = '/TestFilter::in_str_consume';
# send a message bigger than 8k, so to make sure that the input filter
# will get more than one bucket brigade with data.
my $data = A 22 chars long string x 500; # about 11k
my $received = POST_BODY $location, content = $data;
my $expected = read just the first 1024b from the first brigade;
ok t_cmp($expected, $received, input stream filter partial consume)
1.1 modperl-2.0/t/filter/TestFilter/in_str_consume.pm
Index: in_str_consume.pm
===
package TestFilter::in_str_consume;
# this test verifies that streaming filters framework handles
# gracefully the case when a filter doesn't print anything at all to
# the caller. I figure it's absolutely doesn't matter if the incoming
# bb from the upstream is consumed or not. What matter is that the
# filter sends something downstream (an empty bb will do).
#
# e.g. a filter that cleans up the incoming stream (extra spaces?)
# might reduce the whole bb into nothing (e.g. if it was made of only
# white spaces) then it should send down.
#
# another problem with not reading in the while() loop, is that the
# eos bucket won't be detected by the streaming framework and
# consequently won't be sent downstream, probably breaking other
# filters who rely on receiving the EOS bucket.
use strict;
use warnings FATAL = 'all';
use Apache::Filter ();
use Apache::Const -compile = qw(OK M_POST);
sub handler {
my($filter, $bb, $mode, $block, $readbytes) = @_;
my $ctx = $filter-ctx;
unless ($ctx) {
# read a bit from the first brigade and leave the second
# brigade completely unconsumed. we assume that there are two
# brigades because the core input filter will split data in
# 8kb chunks per brigade and we have sent 11k of data (1st bb:
# 8kb, 2nd bb: ~3kb)
my $len = $filter-read($mode, $block, $readbytes, my $buffer, 1024);
warn FILTER READ: $len bytes\n;
$filter-print(read just the first 1024b from the first brigade);
$filter-ctx(1);
}
else {
unless ($filter-seen_eos) {
# XXX: comment out the next line to reproduce the segfault
$filter-print();
}
}
return Apache::OK;
}
sub response {
my $r = shift;
$r-content_type('text/plain');
if ($r-method_number == Apache::M_POST) {
my $data = ModPerl::Test::read_post($r);
#warn HANDLER READ: $data\n;
$r-print($data);
}
return Apache::OK;
}
1;
__DATA__
SetHandler modperl
PerlResponseHandler TestFilter::in_str_consume::response
Re: mod_perl 2.0 and print/send_http_header method SEGFAULT
On Wed, Jan 15, 2003 at 09:09:37AM +1100, Stas Bekman wrote: I've applied a fix that hopefully cures this thing in cvs. Please try again with the latest cvs version. http://perl.apache.org/download/source.html#2_0_Development_Source_Distribution I installed the CVS version (1.9909) and I still get a SEGFAULT when using $r-send_http_header() or $r-print() ... - I fetched the mod_perl CVS sources then launched : $ perl Makefile.PL MP_APXS=/usr/sbin/apxs $ make $ make install - modified the /etc/httpd/conf.d/perl.conf file - restarted httpd I also tested with the Apache::ProxyPassThru module (from http://perl.apache.org/dist/contrib/ProxyPassThru.pm) I added a use Apache::compat statement, removed the $r-handler()/$r-push_handlers() part and I also get a SEGFAULT when it reach the http_send_header() statement ... --
Re: mod_perl 2.0 and print/send_http_header method SEGFAULT
I grep'ed into the mod_perl sources and found in
examples/lib/Apache/HelloWorld.pm that send_http_header does not exists
in mod_perl 2.0 and print is not yet implemented. Is this right ? so
this could easily explain my problems :)
in examples/lib/Apache/HelloWorld.pm :
[...]
sub handler {
my $r = shift;
$r-content_type('text/plain');
#send_http_header API function does not exist in 2.0
$r-puts(__PACKAGE__); #print not yet implemented
return Apache::OK;
}
[...]
--
Re-installing 1.99_08 binary or 1.99_05 RPM in Red Hat 8 [mp2]
I'm new to mod_perl, and was having fun tinkering with mod_perl-1.99_05-3 on Red Hat 8 (Perl 5.8.0 / Kernel 2.4.18-17.8.0 on an i686 / Apache/2.0.40), installed from RPM's. I wanted to get the older Apache:: modules to work, I noted that the ones i wanted came with mod_perl-1.27, and made the (*very* bad) decision of trying to install the old version and getting mod_perl2 to work in 'compatibility mode'. So I tried to install 1.27 from the binary which of course required Apache 1.3, which I had - but not the sources. This resulted in a broken mod_perl installation and me only having some of the modules I required, which of course mostly fail anyway due to dependency issues. I dont think I can install from mod_perl-1.99_08.tar.gz: I hunted for a value for MP_AP_PREFIX - it's probably due to me having installed Apache from an RPM, but there is no path under which the include/ directory with Apache C header files can be found that I can find - something a bit more concrete to feed into 'slocate' or 'find' might help here. Apache/2.0.40 Server compiled with -D APACHE_MPM_DIR=server/mpm/prefork -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 -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=/etc/httpd -D SUEXEC_BIN=/usr/sbin/suexec [snip] Also now the RPM is broken: [root@fooTowers public]# rpm -e --nodeps mod_perl-1.99_05-3.i386.rpm error: package mod_perl-1.99_05-3.i386.rpm is not installed [root@fooTowers public]# rpm -ivh mod_perl-1.99_05-3.i386.rpm Preparing...### [100%] package mod_perl-1.99_05-3 is already installed Nice. Essentially I just want to get mod_perl 2 working again and forget using the old Apache:: modules, either using the 1.99_08 binary or the 1.99_05-3 RPM. Any suggestions much appreciated! TIA, Jon
The best place for mod_perl beginners to get started.
To those of you on this mailing that wonder what is the best way to get started with mod_perl should check out Writing Apache Modules with Perl and C. This book is coauthored by Lincoln Stein (creator of CGI.pm) and Doug MacEachern (creator of mod_perl). I am only half way through the book and have increased my understanding of mod_perl 100%. And for your info, I bought the book used from Amazon.com for 5 dollars. Best book I have ever purchased by O'Reilly (next to Programming Perl) Michael Shirk Bel Air, MD http://www.shirkdog.com _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus
RE: The best place for mod_perl beginners to get started.
You mean you DIDN'T buy Where's Wally ?!!! -Original Message- From: Michael Shirk [mailto:[EMAIL PROTECTED]] To those of you on this mailing that wonder what is the best way to get started with mod_perl should check out Writing Apache Modules with Perl and C. This book is coauthored by Lincoln Stein (creator of CGI.pm) and Doug MacEachern (creator of mod_perl). I am only half way through the book and have increased my understanding of mod_perl 100%. And for your info, I bought the book used from Amazon.com for 5 dollars. Best book I have ever purchased by O'Reilly (next to Programming Perl) Michael Shirk Bel Air, MD
Apache::AuthDBI Extension
Title: Message At our company we're looking at making an extension on top of AuthDBI that would allow us to make mandatory password changes, match new passwords against dictionaries and other security changes. Hasanyone done something similar already? Thanks, Brian Hann
Re: The best place for mod_perl beginners to get started.
Michael Shirk wrote: To those of you on this mailing that wonder what is the best way to get started with mod_perl should check out Writing Apache Modules with Perl and C. This book is coauthored by Lincoln Stein (creator of CGI.pm) and Doug MacEachern (creator of mod_perl). I am only half way through the book and have increased my understanding of mod_perl 100%. and don't forget about the cookbook http://www.modperlcookbook.org/ :) but the best place to really get started is the mod_perl homepage http://perl.apache.org/ where you can find links to all the above, as well as the indispensible mod_perl guide: http://perl.apache.org/docs/1.0/guide/index.html --Geoff
Re: Re-installing 1.99_08 binary or 1.99_05 RPM in Red Hat 8 [mp2]
On Wed, Jan 15, 2003 at 03:07:14PM +, Jon wrote: I have now uninstalled the RPM, but unfortunately: [root@fooTowers mod_perl-1.99_08]# perl Makefile.PL MP_APXS=/usr/sbin/apxs Reading Makefile.PL args from @ARGV MP_APXS = /usr/sbin/apxs !!! Unable to determine server version, aborting. !!! Invalid MP_APXS specified? The only filename containing apxs is in the Apache manual. (I have mod_so compiled in to the httpd.) You must install the httpd-devel package, /usr/sbin/apxs is in this package. I reinstalled the mod_perl-1.99_05-3 RPM thinking that might give me less problems, it looked OK but now: [Wed Jan 15 14:37:02 2003] [error] failed to resolve handler `ModPerl::Registry::handler' [Wed Jan 15 14:43:12 2003] [error] [client 192.168.1.30] Can't locate ModPerl/Registry/handler.pm in @INC (@INC contains: [snip] ... this is using the default conf.d/perl.conf that comes with the RPM (all I changed was the Directory ... location to one which used to work): LoadModule perl_module modules/mod_perl.so # [snip] Directory /home/httpd/html/mp SetHandler perl-script PerlHandler ModPerl::Registry::handler PerlOptions +ParseHeaders Options +ExecCGI /Directory @INC includes /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi and I have: /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/ModPerl/Registry.pm but this is going into the realms of general Perl questions ... I'm wondering what I need to tweak to get the RPM to work, or a working parameter to pass to Makefile.PL Did you stopped and restarted httpd after installing the package ? --
Re: Timestamp for Apache::Upload uploads.
Matthew Hodgson [EMAIL PROTECTED] writes: [...] It seems that the question is less to do with mod_perl, and more to do with whether any current browsers give Last-Modified or Modification-Date or similar information in the MIME headers for multipart/form-data uploads. Whilst I had convinced myself that I'd seen this working, I'm starting to doubt my memory. Not to my knowledge; I suspect you've been stat()ing the spooled temp file all along. -- Joe Schaefer
Re: The best place for mod_perl beginners to get started.
--- Geoffrey Young [EMAIL PROTECTED] wrote: and don't forget about the cookbook http://www.modperlcookbook.org/ Speaking of that, why is it missing from http://perl.apache.org/? Chris
Re: Re-installing 1.99_08 binary or 1.99_05 RPM in Red Hat 8 [mp2]
--- Jon [EMAIL PROTECTED] wrote: This RPM was working before, so all my messing around has broken something I can't find. If the recommendation is to ditch the RPM and proceed with the new binary then that's fine. thanks again, jon Red Hat's RPM seems very friendly at first then it turns into the devil from hell, at least for me :) I had the same problem as you when installing Perl 5.8 and apache/mod_perl on RH 7.1 using RPM. Everything was a dependency issue and got F'ed up. I finally learned how to build from source...
RE: 1.3.27 DSO hassles
I was attempting to configure mod_perl first before factoring in mod_ssl. I cannot find the library that contains the symbol __floatdisf. It's not in libcrypt or libssl libraries from openssl, it does not appear to be in any library in /usr/lib or /lib. The symbol is not defined in any Apache object file either. I'm kinda stumped ont this. I was thinking of upgrading to Solaris 8. Thanks as -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Monday, January 13, 2003 4:29 PM To: Sinclair, Alan (CORP, GEAccess) Cc: '[EMAIL PROTECTED]' Subject: Re: 1.3.27 DSO hassles Sinclair, Alan (CORP, GEAccess) wrote: All, Having been successfully using modperl for the last 2 years statically linked with Apache, I have been trying again to make modperl work with 1.3.27 when the Apache core modules are loaded as DSOs. There has been some traffic in the past on this subject and I checked the archives and followed through on some of the suggestions - Recompiled perl 5.6 with the --Ubincompat5005 option for specific use with modperl - Setup modperl using the perl compiled with --Ubincompat5005 - I use the following configure options for the APACI for Apache 1.3.27 ./configure --prefix=/opt/apache-so \ --enable-rule=SHARED_CORE \ --enable-module=most \ --enable-shared=max \ --activate-module=src/modules/perl/libperl.a \ --disable-shared=perl Apache is compiled and statically links modperl without any problems (Solaris 2.6). When Apache is executed, I receive this error: fatal: relocation error: file /opt/apache-so/libexec/mod_negotiation.so: symbol __floatdisf: referenced symbol not found I have tried the recommendations, specifically the issue with perl's malloc on Solaris which can be corrected with the --Ubincompat5005 option. There were some suggestions offered in this thread (large files CFLAGS?) http://marc.theaimsgroup.com/?t=10168427183r=1w=2 Though I didn't see a success report. If somebody on Solaris 2.6 were able to get it to work, please chime in. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: The best place for mod_perl beginners to get started.
Chris Shiflett wrote: --- Geoffrey Young [EMAIL PROTECTED] wrote: and don't forget about the cookbook http://www.modperlcookbook.org/ Speaking of that, why is it missing from http://perl.apache.org/? I guess that when the mason book came out, it replaced the cookbook image on the left navbar. all related books are listed on the website, though, you just have to dig for them. http://perl.apache.org/docs/offsite/books.html while the move away from the front page definitely decreased our exposure (as I can tell from our weblogs) it's good to share the limelight - mason is a cool mod_perl technology, ken and dave worked just as hard on their book as we did on ours, and it's been getting good reviews. what would be really cool might be reducing the slots to one or two, then have a rotating schedule (script, or whatever) for all books on the list. that would get the slash book in there as well. --Geoff
Re: 1.3.27 DSO hassles
Hi-- I also had this problem when I built on Solaris (2.7). Here is how I fixed it: The symbol is in libgcc.a. Use gcc -print-libgcc-file-name to see where that file is. Now, delete mod_negotiation.so and re-make. See how make does the link. Then, just re-link adding the file to the command line. I think you have to do it for one other module as well, but I don't remember which one. I never came up with a fully automated way to do it, but I didn't rebuild Apache that often. -P - Original Message - From: Sinclair, Alan (CORP, GEAccess) [EMAIL PROTECTED] To: Sinclair, Alan (CORP, GEAccess) [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, January 15, 2003 12:40 PM Subject: RE: 1.3.27 DSO hassles I was attempting to configure mod_perl first before factoring in mod_ssl. I cannot find the library that contains the symbol __floatdisf. It's not in libcrypt or libssl libraries from openssl, it does not appear to be in any library in /usr/lib or /lib. The symbol is not defined in any Apache object file either. I'm kinda stumped ont this. I was thinking of upgrading to Solaris 8. Thanks as -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Monday, January 13, 2003 4:29 PM To: Sinclair, Alan (CORP, GEAccess) Cc: '[EMAIL PROTECTED]' Subject: Re: 1.3.27 DSO hassles Sinclair, Alan (CORP, GEAccess) wrote: All, Having been successfully using modperl for the last 2 years statically linked with Apache, I have been trying again to make modperl work with 1.3.27 when the Apache core modules are loaded as DSOs. There has been some traffic in the past on this subject and I checked the archives and followed through on some of the suggestions - Recompiled perl 5.6 with the --Ubincompat5005 option for specific use with modperl - Setup modperl using the perl compiled with --Ubincompat5005 - I use the following configure options for the APACI for Apache 1.3.27 ./configure --prefix=/opt/apache-so \ --enable-rule=SHARED_CORE \ --enable-module=most \ --enable-shared=max \ --activate-module=src/modules/perl/libperl.a \ --disable-shared=perl Apache is compiled and statically links modperl without any problems (Solaris 2.6). When Apache is executed, I receive this error: fatal: relocation error: file /opt/apache-so/libexec/mod_negotiation.so: symbol __floatdisf: referenced symbol not found I have tried the recommendations, specifically the issue with perl's malloc on Solaris which can be corrected with the --Ubincompat5005 option. There were some suggestions offered in this thread (large files CFLAGS?) http://marc.theaimsgroup.com/?t=10168427183r=1w=2 Though I didn't see a success report. If somebody on Solaris 2.6 were able to get it to work, please chime in. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: The best place for mod_perl beginners to get started.
At 19:14 15.01.2003, Geoffrey Young wrote: Chris Shiflett wrote: --- Geoffrey Young [EMAIL PROTECTED] wrote: and don't forget about the cookbook http://www.modperlcookbook.org/ Speaking of that, why is it missing from http://perl.apache.org/? I guess that when the mason book came out, it replaced the cookbook image on the left navbar. all related books are listed on the website, though, you just have to dig for them. http://perl.apache.org/docs/offsite/books.html while the move away from the front page definitely decreased our exposure (as I can tell from our weblogs) it's good to share the limelight - mason is a cool mod_perl technology, ken and dave worked just as hard on their book as we did on ours, and it's been getting good reviews. what would be really cool might be reducing the slots to one or two, then have a rotating schedule (script, or whatever) for all books on the list. that would get the slash book in there as well. Actually, I put in place such a rotation scheme, but given the fact that we don't rebuild the whole website each day, my system didn't work. I'm at fault here, I should actually change it, and add the Slash book, but I haven't had much time. Sorry. If anyone else can do it, great; if not, I'll get to it when I get more time. -- Per Einar Ellefsen [EMAIL PROTECTED]
reading cookies from mod_perl HTTP request handlers
Hi,
I'm unable to access/read cookies from incoming HTTP requests using
mod_perl HTTP request handlers.Here's what my relevant apache config
section looks like
Location /
PerlHeaderParserHandler MyModule::header_parse_handler
/Location
My browser already has a cookie named 'foo' with value 'bar' with path
expire times set appropriately. Here's what my browser GET request looks
like
GET /cgi-bin/login HTTP/1.1
Host: xx
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1)
Gecko/20021130
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1
Accept-Language: en-us, en;q=0.50
Accept-Encoding: gzip, deflate, compress;q=0.9
Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Connection: keep-alive
Cookie: foo=bar
The last line confirms that the browser is sending the cookie.
But, I'm not able to see that cookie when I print $ENV{'HTTP_COOKIE'}
within in header_parse_handler. mod_perl docs say that that you can
examine request headers in the PerlHeaderParserHandler. Am I missing
something? Am I using a wrong handler? Please help.
thanks
-vish
Re: reading cookies from mod_perl HTTP request handlers
But, I'm not able to see that cookie when I print $ENV{'HTTP_COOKIE'}
within in header_parse_handler.
%ENV is setup during the fixup phase, so it hasn't been populated yet.
mod_perl docs say that that you can
examine request headers in the PerlHeaderParserHandler.
yes, using something like $r-headers_in. you're actually better off using
Apache::Cookie, which is in the libapreq distribution on cpan.
if you want to force %ENV to be setup earlier, try calling
$r-subprocess_env;
in a void context before checking %ENV - it used to segfault for me, but the
docs says it should work.
HTH
--Geoff
Re: reading cookies from mod_perl HTTP request handlers
On Wed, 2003-01-15 at 14:24, Geoffrey Young wrote: if you want to force %ENV to be setup earlier, try calling $r-subprocess_env; in a void context before checking %ENV - it used to segfault for me, but the docs says it should work. This worked for me! Thanks a million! -vish
RE: 1.3.27 DSO hassles
Here's the solution to resolve the __floatdisf symbol error. Thanks to Paul Weiss who provided the hint. Configure and install Apache Relink mod_negotiation.so with libgcc.a (I opted to statically link mod_perl into the core) cd apache_1.3.27/src/modules ld -G -o mod_negotiation.so mod_negotiation.lo /pathto/libgcc.a This will extract the floatdisf function from libgcc.a and link it into mod_negotiation.so which can be verified with nm. The libgcc.a archive will be contained into your gcc build tree under gcc-3.2.1/gcc Thanks to all who replied. Alan -Original Message- From: Paul Weiss [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 15, 2003 11:20 AM To: Sinclair, Alan (CORP, GEAccess); [EMAIL PROTECTED] Subject: Re: 1.3.27 DSO hassles Hi-- I also had this problem when I built on Solaris (2.7). Here is how I fixed it: The symbol is in libgcc.a. Use gcc -print-libgcc-file-name to see where that file is. Now, delete mod_negotiation.so and re-make. See how make does the link. Then, just re-link adding the file to the command line. I think you have to do it for one other module as well, but I don't remember which one. I never came up with a fully automated way to do it, but I didn't rebuild Apache that often. -P - Original Message - From: Sinclair, Alan (CORP, GEAccess) [EMAIL PROTECTED] To: Sinclair, Alan (CORP, GEAccess) [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, January 15, 2003 12:40 PM Subject: RE: 1.3.27 DSO hassles I was attempting to configure mod_perl first before factoring in mod_ssl. I cannot find the library that contains the symbol __floatdisf. It's not in libcrypt or libssl libraries from openssl, it does not appear to be in any library in /usr/lib or /lib. The symbol is not defined in any Apache object file either. I'm kinda stumped ont this. I was thinking of upgrading to Solaris 8. Thanks as -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Monday, January 13, 2003 4:29 PM To: Sinclair, Alan (CORP, GEAccess) Cc: '[EMAIL PROTECTED]' Subject: Re: 1.3.27 DSO hassles Sinclair, Alan (CORP, GEAccess) wrote: All, Having been successfully using modperl for the last 2 years statically linked with Apache, I have been trying again to make modperl work with 1.3.27 when the Apache core modules are loaded as DSOs. There has been some traffic in the past on this subject and I checked the archives and followed through on some of the suggestions - Recompiled perl 5.6 with the --Ubincompat5005 option for specific use with modperl - Setup modperl using the perl compiled with --Ubincompat5005 - I use the following configure options for the APACI for Apache 1.3.27 ./configure --prefix=/opt/apache-so \ --enable-rule=SHARED_CORE \ --enable-module=most \ --enable-shared=max \ --activate-module=src/modules/perl/libperl.a \ --disable-shared=perl Apache is compiled and statically links modperl without any problems (Solaris 2.6). When Apache is executed, I receive this error: fatal: relocation error: file /opt/apache-so/libexec/mod_negotiation.so: symbol __floatdisf: referenced symbol not found I have tried the recommendations, specifically the issue with perl's malloc on Solaris which can be corrected with the --Ubincompat5005 option. There were some suggestions offered in this thread (large files CFLAGS?) http://marc.theaimsgroup.com/?t=10168427183r=1w=2 Though I didn't see a success report. If somebody on Solaris 2.6 were able to get it to work, please chime in. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Passing CGI environment to subprograms
Thanks for the reply, just getting back from a short vacation...
My test programs:
first.pl
---
#!/export/home/eoliphan/gnu/bin/perl -w
use strict;
my $key;
open(LOG, /tmp/firstdebug.log);
foreach $key (keys %ENV)
{
print LOG $key = $ENV{$key} \n;
}
`/export/home/eoliphan/gnu/cgi-bin/dump_vars.pl`;
close (LOG);
---
dump_vars.pl has the same foreach loop and dumps to a different log file.
The 'firstdebug.log' has the required CGI vars. The log generated by
dump_vars.pl has what appears to be the enviroment of the httpd executable
and no CGI vars.
Erich
- Original Message -
From: Stas Bekman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, January 09, 2003 10:01 PM
Subject: Re: Passing CGI environment to subprograms
I don't see any reason why your `` invoked process doesn't see the CGI
env vars. For example:
#!/usr/bin/perl
print Content-type: text/plain\n\n;
$ENV{'PATH'} = '/bin:/usr/bin';
delete @ENV{'IFS', 'CDPATH', 'ENV', 'BASH_ENV'};
print qx{printenv |grep REMOTE_ADDR};
prints:
REMOTE_ADDR=127.0.0.1
So as you can see, it works. The problem is probably in your external
program, since the env vars are all there.
Or may be you are using PerlSetEnv Off?
http://perl.apache.org/docs/1.0/guide/config.html#PerlSetupEnv
I've now located and tried the subprocess_env() in conjunction w/
spawn_proc_prog(). I just do a foreach on the ENV hash and stuff
the values
into subprocess_env(). That works (I have a test perl subprogram
that just
dumps the ENV), but now I am not able to get the output of the program.
I
pasted in the read_data() func from the example and I have a single
scalar
accepting the return value from spawn_proc_prog() per the example
and that
is supposed to give me the output filehandle.
Can you post a simple test program that reproduces the problem?
Also it'd be really useful if somebody could add a test suite for
Apache::Subprocess for (mod_perl 1.0). You can look at the
t/apr/subprocess test in mod_perl 2.0 to a basic example. It's a good
way to learn how to use Apache::Test, which is covered here:
http://perl.apache.org/docs/general/testing/testing.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
Re: mod_perl 2.0 and print/send_http_header method SEGFAULT
Jérôme Augé wrote:
On Wed, Jan 15, 2003 at 09:09:37AM +1100, Stas Bekman wrote:
I've applied a fix that hopefully cures this thing in cvs. Please try
again with the latest cvs version.
http://perl.apache.org/download/source.html#2_0_Development_Source_Distribution
Since you've never sent the backtrace of SEGFAULT, as explained here:
http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems
there can be more than one problem. I've fixed one, but there can be more
lurking behind the first one. So if you can send the backtrace, that will
help a lot.
I installed the CVS version (1.9909) and I still get a SEGFAULT when
using $r-send_http_header() or $r-print() ...
- I fetched the mod_perl CVS sources then launched :
$ perl Makefile.PL MP_APXS=/usr/sbin/apxs
$ make
$ make install
- modified the /etc/httpd/conf.d/perl.conf file
- restarted httpd
Cool. Now can you please send the shortest possible example that you still
get the SEGFAULT with, so I can reproduce it and fix? Thanks.
I also tested with the Apache::ProxyPassThru module (from
http://perl.apache.org/dist/contrib/ProxyPassThru.pm)
I added a use Apache::compat statement, removed the
$r-handler()/$r-push_handlers() part and I also get a SEGFAULT when it
reach the http_send_header() statement ...
send_http_header is indeed doesn't exist in 2.0, but implemented in
Apache::compat and should work just fine, as it's exercised in many tests:
grep -Ir send_http_header t
t/compat/request_body.t:# $r-send_http_header('text/plain');
t/compat/request_body.t:q{$r-send_http_header('text/plain')}
t/response/TestCompat/request_body.pm:$r-send_http_header('text/plain');
t/response/TestCompat/apache.pm:$r-send_http_header('text/plain');
t/response/TestCompat/apache_file.pm:$r-send_http_header('text/plain');
t/response/TestCompat/apache_table.pm:$r-send_http_header('text/plain');
t/response/TestCompat/apache_util.pm:$r-send_http_header('text/plain');
t/response/TestCompat/request.pm:$r-send_http_header('text/plain');
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: mod_perl 2.0 and print/send_http_header method SEGFAULT
Jérôme Augé wrote:
I grep'ed into the mod_perl sources and found in
examples/lib/Apache/HelloWorld.pm that send_http_header does not exists
in mod_perl 2.0 and print is not yet implemented. Is this right ? so
this could easily explain my problems :)
It's an old example, I've removed it.
in examples/lib/Apache/HelloWorld.pm :
[...]
sub handler {
my $r = shift;
$r-content_type('text/plain');
#send_http_header API function does not exist in 2.0
$r-puts(__PACKAGE__); #print not yet implemented
return Apache::OK;
}
[...]
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Re-installing 1.99_08 binary or 1.99_05 RPM in Red Hat 8 [mp2]
Jon wrote: At 16:34 15/01/2003 +0100, Jérôme Augé wrote: You must install the httpd-devel package, /usr/sbin/apxs is in this package. OK, I've installed this, but I would like one more go at getting the RPM working, so I don't get more problems when the next RPM is released - I guess I have to choose one method to follow, but am more used to dealing with RPM's. I reinstalled the mod_perl-1.99_05-3 RPM thinking that might give me less problems, it looked OK but now: [Wed Jan 15 14:37:02 2003] [error] failed to resolve handler `ModPerl::Registry::handler' [Wed Jan 15 14:43:12 2003] [error] [client 192.168.1.30] Can't locate ModPerl/Registry/handler.pm in @INC (@INC contains: [snip] Try with the 99_08 version. it should be pretty easy to grab the src package for mod_perl-1.99_05-3, rpm -i it, replace the modperl tar.gz in the SOURCES dir, adjust the spec file and rebuild a new package. But I'd go with the build from source. At least to get you going. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: 1.3.27 DSO hassles
Sinclair, Alan (CORP, GEAccess) wrote: Here's the solution to resolve the __floatdisf symbol error. Thanks to Paul Weiss who provided the hint. Configure and install Apache Relink mod_negotiation.so with libgcc.a (I opted to statically link mod_perl into the core) cd apache_1.3.27/src/modules ld -G -o mod_negotiation.so mod_negotiation.lo /pathto/libgcc.a This will extract the floatdisf function from libgcc.a and link it into mod_negotiation.so which can be verified with nm. The libgcc.a archive will be contained into your gcc build tree under gcc-3.2.1/gcc Thanks to all who replied. Fantastic! I've documented this solution at http://perl.apache.org/docs/1.0/guide/troubleshooting.html (auto-update pending) Thank you! __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [mp2] config: $Listen won't listen.
Dmitri Tikhonov wrote: Hi everyone, I just upgraded to 1.99_08, and it lets me do all my old Perl configurations. Except for one. When I try to do something like Perl push @Listen, 80; # or this: # $Listen = 80; /Perl Apache refuses to bind to that port, telling me that the socket is already in use. No matter which port I specify, this happens. My question is, does this happen because of when Perl directives are actually processed (too late for Listen?), and if so, how would I go about determining which port to listen on dynamically? My setup: apache 2.0.43, mod_perl 1.99_08. Thanks in advance, - Dmitri. P.S. Any word on when more more documentation for Perl configuration is coming? I think that Philippe is on vacation now and he promised to commit a fixed version once he comes back. I believe that once it works completely it'll be the time to add docs. Though if you can contribute the docs (should be pretty easy since all you need is to port them from 1.0 guide/eagle book/cookbook) that would help a lot so we can spend more time coding the old/new features, rather than writing docs. While you've asked about the docs. This is a call for everyone who's playing/developing with 2.0. If you see that some docs are missing, please send patches against the modperl-docs cvs repository. Most of the time all you need is to port the docs from 1.0. Your help is *very* appreciated. Post the patches here, or the docs-dev list. Thanks. __ 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
