tru64/Configure problem with perl5.6.0 for modperl
Hi, I'm in process of upgrading our perl/modperl/apache installation, and have a problem. Not sure if this is a perl problem or a modperl problem. modperl-1.24/perl-5.6.0/tru64-D/apache-1.3.14 I'm gettting the ./Configure fail with: + doing sanity check on compiler and options ** A test compilation with your Makefile configuration ** failed. The below error output from the compilation ** test will give you an idea what is failing. Note that ** Apache requires an ANSI C Compiler, such as gcc. Error Output for sanity check cd ..; gcc -DOSF1 -DUSE_HSREGEX -DUSE_EXPAT -I./lib/expat-lite -DNO_DL_NEEDED -std -fprm d -ieee -D_INTRINSICS -I/usr/include_ndbm -I/usr/local/include -DLANGUAGE_C -DMOD_PERL -o helpers/dummy helpers/dummy.c `/usr/local/perl-5.6.0/bin/perl /usr/local/perl-5.6.0/source_apache_modperl/apache_1.3.14/mod_perl-1.24/src/modules/perl/ldopts ` -lm gcc: d: No such file or directory cc1: Invalid option `-std' It's trying to use the compiled defaults that I've made perl-5.6.0 with (eg. -std) that work with digital cc, but not with gcc, this is a bit from the perl -V for 5.6.0 Compiler: cc='cc', optimize='-O4', gccversion= cppflags='-std -ieee -D_INTRINSICS -I/usr/local/include -DLANGUAGE_C' when I use the installed perl (5.0 patch4 sublevel4) I don't get this problem. This was build with digital cc and shows built with non-gcc flags: eg; Compiler: cc='cc', optimize='-O4', gccversion= cppflags='-std -D_INTRINSICS -I/usr/local/include -D__LANGUAGE_C__' Have I misinstalled the new perl or is this a modperl problem (or something else)? Cheers, Bob
Very WIRED error msg
Hello guys , I saw this : [Mon Oct 23 14:45:09 2000] [notice] Apache/1.3.12 (Unix) mod_perl/1.24 configured -- resuming normal operations Argument "OK" isn't numeric. Argument "OK" isn't numeric. Argument "OK" isn't numeric. Argument "OK" isn't numeric. etc.. What that mean ??? Thanks - La messagerie itinérante sans abonnement NetCourrier - Web : www.netcourrier.com Minitel : 3615 et 3623 NETCOURRIER Tél : 08 36 69 00 21
Re: Very WIRED error msg
Hi - Original Message - From: [EMAIL PROTECTED] Argument "OK" isn't numeric. Argument "OK" isn't numeric. Argument "OK" isn't numeric. Argument "OK" isn't numeric. What that mean ??? Your code is expecting a numeric value [probably 1 or 0] and it's getting a string. Your code is expecting a numeric value [probably 1 or 0] and it's getting a string. Your code is expecting a numeric value [probably 1 or 0] and it's getting a string. Your code is expecting a numeric value [probably 1 or 0] and it's getting a string. \js
Re: Very WIRED error msg
Argument "OK" isn't numeric.
Argument "OK" isn't numeric.
Argument "OK" isn't numeric.
Argument "OK" isn't numeric.
It looks like you are trying to check the return value from a mod_perl
handler.
my $foo = handler();
if($foo == 1){
# this won't work :)
}
sub handler {
...
return OK;
}
Re: IPC::Shareable (was Re: Perl module - LWP)
On Sun, 22 Oct 2000, Steven Cotton wrote:
What version of Perl are you using? I had some problems with make test,
one of the tests doesn't return and I got a few munged shared memory
segment errors, I was attempting to install under Solaris 7 and Perl
5.6.0.
The messages about "munged shared memory" seem to be going if you change
my($tag, $ice) = unpack 'A14 A*' = $stuff;
in the file lib/IPC/Shareable.pm, sub _thaw to the:
my($tag, $ice) = unpack 'A13 A*' = $stuff;
(since the sub _freeze calls
my $stuff = 'IPC::Shareable' . $ice;
- i.e. 13 chars). But there are further problems ("make test" hangs)...
Re: IPC::Shareable (was Re: Perl module - LWP)
my $stuff = 'IPC::Shareable' . $ice; - i.e. 13 chars) Oops, sorry - I can't count on mondays!
Re: persistent database problem
The db connection happens once for each child - so every time you hit a
child for the first time it will open up a new connection - you probably
have apache configured to start with 4 or so kids.
sterling
On Mon, 23 Oct 2000,
Differentiated Software Solutions Pvt. Ltd wrote:
Hi,
I have started with one httpd; and executed the following mod-perl program from
the browser. We've configured apache to have persistent DBI
The idea is first time the database handle will be inactive and it will print
'INSIDE'. From the second time onwards the database handle will be active and it
will print 'OUTSIDE'. This is working.
But, sometimes the 'OUTSIDE' comes from the third or fourth time only. (that is
it takes more than one attempt to become persistent) Why it is happening like this?
Thanks
Muthu S Ganesh
mod-perl code is here:
$rc = $dbh_pg-{Active};
print "$$: $rc\n";
if($rc eq '')
{
print "INSIDE\n";
$dbh_pg =
DBI-connect("dbi:Pg:dbname=adcept_smg_ctrl","postgres","postgres",{RaiseError = 1})
|| die $DBI::errstr;
}
else
{
print "OUTSIDE\n";
}
Differentiated Software Solutions Pvt. Ltd.
176, Ground Floor, 6th Main,
2nd Block, RT Nagar
Bangalore - 560032
Phone : 91 80 3431470
www.diffs-india.com
Re: child seg fault (11) with mod_perl as DSO (Sol 8, perl 5.6, gcc 2.95.2)
* Gary Goldberg | | Hello. I am build a machine from scratch, so I've done this: | | 1. Installed clean Solaris 8 Intel. | 2. Installed SFWgcc (2.95.2) from Solaris install. | 3. Used Solaris-installed perl 5.005 to build perl 5.6 in /opt. (Everything | in /opt). | 4. Used CPAN to install libnet, MD5, CPAN bundles. | 5. Installed Mysql 3.23.26 into /opt. | 6. Installed Bundle::Mysql, Bundle::Apache using CPAN. | 7. Installed Berkeley db 3.1 into /opt. | 8. Reinstalled perl 5.6 using -Ubincomat5005 enabling large file support. | 8. Used clean dists of apache 1.3.14, php 4.03pl1, mod_perl 1.24. | |Built apache using suexec config, --enable=module=most --enable-shared-max |with largefile support. Make, install. | |Built mod_perl using USE_APXS=1 WITH_APXS=/opt/apache/bin/apxs EVERYTHING=1 |and make, install. | |Built php4 using APXS. Make, install. | | Everything seems fine, but when I try to access the status module or the | webroot home page I get "child exit segmentation fault (11)". | | All previous messages in the list archive did not seem to apply, although | I tried their suggestions also. Nothing seems to work and I am stuck | here, Any ideaa? THanks to all in advance, -Gary I've got the same sigsegv problem, though not with perl 5.6.0 only 5.00503 and 500404 and only on linux/x86 and linux/ppc, solaris/usparc works fine. DSO or no DSO doesn't seem to matter. I'm trying to do some debugging of this problem, but haven't gotten very far. Actually I only have the Apache::Status sigsegv on one build on linux/x86. _BUT_ I've got another homemade module that dies on every linux build that doesn't use 5.6. It's a real show stopper, but it's forcing me to learn a little more about gdb and c every day :) Any advances you do in tracing this problem, please let me know. (bo) Head Engineer Center for Information Technology Services University of Oslo
Re: File Space Usage ... in perl ?
See Perl Power Tools - http://language.perl.com/ppt/what.html
[REPOST] MyClass::import() not being called.
Hi all, Did we forget me? (snif, snif...) I've got this happy little access handler that works just fine. I'm loading it like this: PerlAccessHandler MyClass Now I need for it to accept parameters through import(). That would let me change the usage to something like this: PerlAccessHandler MyClass 'extra parameters' The catch is that MyClass::import() isn't being called reguardless of how I load it. I've done all of the obvious stuff, like including lots of debugging messages in the package, reading the docs, reading the Apache modules book, and even searching the archives for this list, no help. Does anybody know what's happening here? Rodney Broom
Re: [REPOST] MyClass::import() not being called.
From: "Carlos Ramirez" [EMAIL PROTECTED] CR You can use PerlSetVar to set parameters like so: CR PerlAccessHandler MyClass CR PerlSetVar Param1 CR PerlSetVar Param2 Yep, that's definately an effective work-around. My biggest concern is the fact that import() doesn't seem to be getting called at all. That sounds broken to me. Rodney Broom
Re: [REPOST] MyClass::import() not being called.
The types of parameters I'll pass to this handler will change machine-by-machine. You see, I need to run this package on several different servers, and need it to know how to configure it's self. Okay... I don't think I get exactly why this situation makes using PerlSetVar impossible/impractical, because if you were thinking that you could write PerlAccessHandler My::Access 'parameters' Why can't you just write PerlAccessHandler My::Access PerlSetVar param1 value1 PerlSetVar param2 value2 So I'm not sure I understand that distinction. *However*, if you really want to use import, couldn't you go about doing so like this: Perl use My::Access 'parameters'; /Perl PerlAccessHandler My::Access If you do that, and define a My::Access::import, it should definitely be called correctly. bye, Ben
Re: [REPOST] MyClass::import() not being called.
[EMAIL PROTECTED] (Rodney Broom) wrote: I've got this happy little access handler that works just fine. I'm loading it like this: PerlAccessHandler MyClass Now I need for it to accept parameters through import(). That would let me change the usage to something like this: PerlAccessHandler MyClass 'extra parameters' The catch is that MyClass::import() isn't being called reguardless of how I load it. I actually wouldn't expect it to call import() with the given parameter list, simply because it's documented to do something else. It's documented to think of the second parameter as another AccessHandler module, as in chained handlers. Remember: PerlModule is the way to load new modules. Ordinarily you should do "PerlModule Blah" to load the module, and then "Perl*Handler Blah" to actually install it as a handler somewhere. However, in recent versions of mod_perl, the "PerlModule Blah" will be done automatically for you if you refer to a previously unseen module as a handler. To me, the exact behavior you're looking for seems like a bad idea, because as Benjamin pointed out, it conflicts with the chained handler syntax. But it seems reasonable that PerlModule might take an import() list. I'm not sure whether it does so now or not. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
cannot install mod_perl-1.24_01/mod_ssl-2.7.1/apache_1.3.14/perl-5.6.0
I've been trying to install the following combination without any luck: mod_perl-1.24_01 mod_ssl-2.7.1 openssl-0.9.6 apache_1.3.14 perl-5.6.0 ...on FreeBSD 2.2.8 Error when making mod_perl: bash-2.02# make ...successful steps cut out... === src/modules/perl === src/modules cc -c -I. -I/usr/local/lib/perl5/5.6.0/i386-freebsd/CORE -I./os/unix -I./inc lude -f unsigned-char -DMOD_SSL=207101 -DMOD_PERL -DUSE_PERL_SSI -I/usr/local/includ e -DEAPI -DNO_DL_NEEDED -I/usr/local/include `./apaci` modules.c cc -c -I. -I/usr/local/lib/perl5/5.6.0/i386-freebsd/CORE -I./os/unix -I./inc lude -f unsigned-char -DMOD_SSL=207101 -DMOD_PERL -DUSE_PERL_SSI -I/usr/local/includ e -DEAPI -DNO_DL_NEEDED -I/usr/local/include `./apaci` buildmark.c cc -funsigned-char -DMOD_SSL=207101 -DMOD_PERL -DUSE_PERL_SSI -I/usr/local/ include - DEAPI -DNO_DL_NEEDED -I/usr/local/include `./apaci` -L/opt/ssl/lib-o httpd buildm ark.o modules.o modules/standard/libstandard.a modules/ssl/libssl.a modules/perl/l ibperl.a main/libmain.a ./os/unix/libos.a ap/libap.a-lcrypt -lssl -lcrypto -L/usr/local/lib /usr/local/lib/perl5/5.6.0/i386-freebsd/auto/DynaLoader/DynaLoader .a -L/usr/local/lib/perl5/5.6.0/i386-freebsd/CORE -lperl -lm -lc -lcrypt DynaLoader.o: Undefined symbol `_Perl_vmess' referenced from text segment *** Error code 1 Stop. What is _Perl_vmess? Could the above error be related to my installation of perl-5.6.0? I was able to compile this version of mod_perl when I had Perl 5.00503. Should I blow 5.6 away and try with 5.00503 again? I appreciate your time and help. Thanks!!! -Will [EMAIL PROTECTED] P.S. Here are more specifics on steps I took: (1) I installed perl-5.6.0 without trouble. I chose all the defaults. As it was installing, I didn't see any error messages or instances where the defaults weren't good. * I wasn't sure whether to override the use "vfork" (?) which was one of the prompts so I went with the default (use "vfork"). * I did not build a shared libperl.so. * I did choose dynamic loading. I'm mentioning the above b/c I'm not really too clear on the implications so they remain suspects in the mystery to me. (2) I installed openssl-0.9.6 as per the instructions. No problems there. (3) I followed the mod_perl instructions in INSTALL.simple.mod_ssl: ash-2.02# cd ../mod_ssl-2.7.1-1.3.14 bash-2.02# ./configure --with-apache=../apache_1.3.14 Configuring mod_ssl/2.7.1 for Apache/1.3.14 + Apache location: ../apache_1.3.14 (Version 1.3.14) + Auxiliary patch tool: ./etc/patch/patch (local) + Applying packages to Apache source tree: o Extended API (EAPI) o Distribution Documents o SSL Module Source o SSL Support o SSL Configuration Additions o SSL Module Documentation o Addons Done: source extension and patches successfully applied. bash-2.02# perl Makefile.PL USE_APACI=1 EVERYTHING=1 SSL_BASE=/opt/ssl APACHE_PREFIX= /opt/apache APACI_ARGS=--enable-module=ssl,--enable-module=rewrite bash-2.02# cd ../mod_perl-1.24_01 bash-2.02# perl Makefile.PL USE_APACI=1 EVERYTHING=1 SSL_BASE=/opt/ssl APACHE_PREFIX= /opt/apache APACI_ARGS=--enable-module=ssl,--enable-module=rewrite Will configure via APACI Configure mod_perl with ../apache_1.3.14/src ? [y] Shall I build httpd in ../apache_1.3.14/src for you? [y] cp apaci/Makefile.libdir ../apache_1.3.14/src/modules/perl/Makefile.libdir cp apaci/Makefile.tmpl ../apache_1.3.14/src/modules/perl/Makefile.tmpl cp apaci/README ../apache_1.3.14/src/modules/perl/README cp apaci/configure ../apache_1.3.14/src/modules/perl/configure cp apaci/libperl.module ../apache_1.3.14/src/modules/perl/libperl.module cp apaci/mod_perl.config.sh ../apache_1.3.14/src/modules/perl/mod_perl.config.sh cp apaci/load_modules.pl.PL ../apache_1.3.14/src/modules/perl/load_modules.pl.PL cp apaci/find_source.PL ../apache_1.3.14/src/modules/perl/find_source.PL cp apaci/apxs_cflags.PL ../apache_1.3.14/src/modules/perl/apxs_cflags.PL cp apaci/mod_perl.exp ../apache_1.3.14/src/modules/perl/mod_perl.exp PerlDispatchHandler.enabled PerlChildInitHandlerenabled PerlChildExitHandlerenabled PerlPostReadRequestHandler..enabled PerlTransHandlerenabled PerlHeaderParserHandler.enabled PerlAccessHandler...enabled PerlAuthenHandler...enabled PerlAuthzHandlerenabled PerlTypeHandler.enabled PerlFixupHandlerenabled PerlHandler.enabled PerlLogHandler..enabled PerlInitHandler.enabled PerlCleanupHandler..enabled PerlRestartHandler..enabled PerlStackedHandlers.enabled PerlMethodHandlers..enabled PerlDirectiveHandlers...enabled PerlTableApienabled PerlLogApi..enabled PerlUriApi..enabled PerlUtilApi.enabled PerlFileApi.enabled PerlConnectionApi...enabled PerlServerApi...enabled PerlSectionsenabled
site using mod_perl
Hi, I use mod_perl on http://www.a-blast.org/ and want to suggest it for http://perl.apache.org/sites.html It is a "truly interactive text network", written completely in mod_perl. For a quick, non-technical overview have a look on http://www.assoziations-blaster.de/prixars/ (its in english on our old domain). About one year ago, it runs on M$ IIS with ActivePerl and some PHP, in the meantime it is completely rewritten as Apache module, using MySQL as database. With this, I speed up the execution time from ~3 Seconds to ~10 milliseconds for each Blast-Page (OK, OK, the old machine had a very worst hardware, now we use only a semi-worst one: Pentium II 350, 320 MB RAM with Soft-RAID 0 under Linux). The blast_engine includes the links into the texts in realtime, also the statistics are created in realtime: http://www.a-blast.org/statistics/ http://www.assoziations-blaster.de/statistik/ (german, with much more traffic) The blaster uses the speed benefit of keeping the complete keyword list in memory (more then 5 MB for the german version), for the non-linear real-time linker I use a ~50 line regexp .-) The HTML-Files are compressed on-the-fly with Compress::Zlib, so we keep bandwidth (and transmission time to the users) small. so, hmmm, if you have any (technical?) questions, feel free to ask ;) The german version has about 5000 visitors and 2 page views per day, which is very good for a non-profit net.art project in germany. Ciao Alvar -- Alvar C.H. Freude | [EMAIL PROTECTED] Demo: http://www.online-demonstration.org/ | Mach mit! Blast-DE: http://www.assoziations-blaster.de/ | Blast-Dich-Fit Blast-EN: http://www.a-blast.org/ | Blast/english
