Re: compiling troubles on Solaris 8
Sun wants to sell you it's Forte for C (formerly known as the Sun Workshop compiler). There's a hundred reasons to use the sun compiler over gcc, and one pretty big reason why you you don't want to use it. If you can get it into your budget, by all means go for the real Sun compiler. It generates code that is highly optimized for sparc hardware, particularly if you are running multiple processors. If nothing else, request a time limited demo license from Sun so you can build mod_perl (and every other module you think you'll ever need off of CPAN). On Sunday, August 5, 2001, at 04:05 PM, Paul Phillips wrote: > Hello, > > I am trying to build mod_perl 1.26 and Apache 1.3.20 on my Solaris 8 > box. I have installed the additional CD with the developer tools > including the gnu utilities and gcc. > > When I first started, it did not seem to be using gcc, so I renamed > /usr/ucb/cc to cc.default, and make /usr/ucb/cc a link to gcc. > > That seemed to get me further. However, I have reached a fatal error, > and don't have a clue what this means. The error messages are quoted > below. > > I am trying to do the simplest build possible, following the INSTALL > instructions. So after unzipping and untarring apache and mod_perl, > from within the mod_perl distribution directory, I type > perl Makefile.PL > I confirm that I want it build from ../apache_1.3.20/src, and that I > want to store the new httpd in that directory. > > Then I type make. After a bit, I get this: > > mkdir ../blib/arch/auto/Apache/Leak > mkdir ../blib/lib/auto/Apache/Leak > cp Leak.pm ../blib/lib/Apache/Leak.pm > /bin/perl -I/usr/perl5/5.00503/sun4-solaris -I/usr/perl5/5.00503 > /usr/perl5/5.00 > 503/ExtUtils/xsubpp -typemap /usr/perl5/5.00503/ExtUtils/typemap > -typemap typem > ap Leak.xs >xstmp.c && mv xstmp.c Leak.c > cc -c -xO3 -xdepend -DVERSION=\"1.00\" -DXS_VERSION=\"1.00\" > -KPIC -I/usr > /perl5/5.00503/sun4-solaris/CORE -DSOLARIS2=280 -DUSE_EXPAT > -I/lib/expat-lite -D > NO_DL_NEEDED Leak.c > cc: unrecognized option `-KPIC' > cc: language depend not recognized > cc: Leak.c: linker input file unused since linking not done > Running Mkbootstrap for Apache::Leak () > chmod 644 Leak.bs > LD_RUN_PATH="" cc -o ../blib/arch/auto/Apache/Leak/Leak.so -G Leak.o > cc: Leak.o: No such file or directory > cc: No input files > *** Error code 1 > make: Fatal error: Command failed for target > `../blib/arch/auto/Apache/Leak/Leak > .so' > Current working directory /home/paul/mod_perl-1.26/Leak > *** Error code 1 > make: Fatal error: Command failed for target `subdirs' > > I have no idea what is wrong, or how to fix it, so I would appreciate > any help. > > thanks! > > ___ > Paul Phillips > Director of Orchestral Activities, Meadows School of the Arts > Southern Methodist University > > "You must sing every note you play, sing even through the rests!" > Arturo Toscanini >
RE: Bug in Apache::ASP XMLSubs when an argument includes '>'-characte rs?
What 'bout $sv=$$hashref{key} instead of $sv=$hashref->{key}? It's one
less character of typing so it's easier on your fingers too!
-Original Message-
From: Henrik Tougaard [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 28, 2000 4:59 AM
To: '[EMAIL PROTECTED]'
Cc: 'Joshua Chamas'
Subject: RE: Bug in Apache::ASP XMLSubs when an argument includes
'>'-characte rs?
Joshua Chamas wrote:
>
> I think > is just about the only thing that you can't use as
> a character in the attributes for an XMLSubs and that's because
> it gets parsed with an aggressive ( or stupid ;) regexp like:
>
> $$data =~ s|\<\s*($self->{xml_subs_match})([^\>]*)/\>
Pity!
I would like to use XMLSubs to capture some HTML-output and do
postprocess them accoring to the attributes.
Eg. if $Response->{UserName} is "Joshua" then bold part of the page.
It could be done something like this:
..some HTML here...
[Stupid example, but I hope you get the idea]
OK the tags are out. I can handle that by making an XMLSub
for every tag-pair that I need, or whatever...
But it is a pian to have to say:
<% $svtwnbu=$Response->{UserName} eq 'Joshua', %>
...more HTML here...
[Where $svtwnbu is some-variable-that-will-never-be-used elsewhere :-]
Not so neat.
Is there a simpler way of doing this?
---
Henrik Tougaard, FOA, Denmark.
RE: Problem with form data using mod_perl and CGI.pm
"perldoc perlref" addresses the nested subroutine problem, and
suggests using something like this:
local *printQueryParams = sub {
instead of this:
sub printQueryParams {
The assignment to the typeglob is pretty slick in that it let's you
call the anonymous subroutine as if it were a subroutine named
printQueryParams.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 14, 2000 3:44 AM
To: Stas Bekman
Cc: Jie Gao; [EMAIL PROTECTED]
Subject: Re: Problem with form data using mod_perl and CGI.pm
Stas Bekman wrote:
>
> On Mon, 14 Aug 2000, stevenl wrote:
>
> > Thanks. That seems to be the problem, accessing an outer lexical
> > variable in an inner subroutine. I'm not quite sure I understand
why
> > Perl behaves this way. Java seems to handle this just fine with
the
> > expected behavior.
>
> Because Perl != Java. And you are lucky that the last statement
> returns true :) Of course the real explanation would require some
reading
> from you.
>
I thought the whole philosophy behind Perl is that it does what you
expect it to do and this is in no way what anyone would expect it to
behave!
Thanks for the link. I guess I'll read up on this guide more
carefully
before I ask any further questions.
-Steven
> > I'm currently using:
> >
> > use CGI;
> > my $query = new CGI();
> >
> > What is the best way to define a global value like $query if I
want to
> > 'use strict'. I really don't want to be passing $query to all my
> > subroutines. I could package define it as $main::query but that
seems
> > awkward.
>
>
http://perl.apache.org/guide/perl.html#Using_Global_Variables_and_Shar
i
>
> > -Steven
> >
> >
> > Jie Gao wrote:
> > >
> > > On Sat, 12 Aug 2000, stevenl wrote:
> > >
> > > > I am running Linux 2.2, Apache 1.3.12, mod_perl 1.24, and
CGI.pm 2.70.
> > > >
> > > > If I declare a CGI variable using 'my' (see below) and use
mod_perl, I
> > > > encounter problems with POST data. On subsequent entries in
the form,
> > > > it continues to use the old data.
> > > >
> > > > The problem does not appear if I don't use 'my' (and
therefore, unable
> > > > to 'use strict'), or if I disable mod_perl from my httpd.conf
file.
> > > >
> > > > You can test this out with these files. First, run
'httpd -X'. Then
> > > > enter some data in the form. On the next submit, the data is
not
> > > > changed.
> > > >
> > > > Note: The perl script displays the current HTML file plus what
you
> > > > just entered.
> > > > ...
> > >
> > >
http://perl.apache.org/guide/perl.html#my_Scoped_Variable_in_Nested_S
> > >
> > > Jie
> >
>
>
_
> Stas Bekman JAm_pH -- Just Another mod_perl
Hacker
> http://stason.org/ mod_perl Guide
http://perl.apache.org/guide
> mailto:[EMAIL PROTECTED] http://apachetoday.com
http://jazzvalley.com
> http://singlesheaven.com http://perlmonth.com perl.org
apache.org
Re: Apache::Session : DBI->Too many connections
Mysql accepts a maximum of 100 connections. This probably means you have MaxClients set at a number larger than this. If you are serving all of your files, including static html and graphics, through one mod_perl enabled apache, run the top command and prepare to pick your jaw off the floor. mod_perl processes are huge and you probably don't need to be running 150 of them. Read http://perl.apache.org/guide/strategy.html and http://perl.apache.org/guide/performance.html if you haven't already. Otherwise it may be that you have things other than mod_perl connecting to MySql in which case you just need to increase its max_connections parameter to a bigger number. - Original Message - From: Frédéric Schwien To: [EMAIL PROTECTED] Sent: Saturday, July 29, 2000 10:31 AM Subject: Apache::Session : DBI->Too many connections Hi , I am using Perl 5.6.0 whith MySql 3.22.32 , Apache 1.3.12 , modperl 1.24 . On our Production Server , Apache error logs are showing sometimes : [Thu Jun 8 14:53:34 2000] [error] DBI->connect failed: Too many connections at /usr/local/lib/perl5/site_perl/5.6.0/Apache/Session/ DBIStore.pm line 117 (in cleanup) DBI->connect failed: Too many connections at /usr/local/lib/perl5/site_perl/5.6.0/Apache/Session/DBIStore.pm li ne 117 Does Anybody knows how solve this ? THanks, Fred __ Sur WebMailS.com, mon adresse de courrier électronique gratuite. Service multilingue, sûr, et permanent. http://www.webmails.com/
Re: What's next for Apache::Session
ditto! - Original Message - From: Igor Chudov @ home <[EMAIL PROTECTED]> To: Jeffrey W. Baker <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, April 28, 2000 8:11 PM Subject: Re: What's next for Apache::Session > reuse of already open database handles is what I was parying for. I use > oracle > > > - Igor.
[slightly OT] redhat linux 6.1
Has anyone built RPMs for redhat 6.1 with apache/1.3.9 and mod_perl 1.2.2 where DSO actually works. If not, I would like to know how to do it. It's a shame that redhat linux 6.1 is shipping with a broken mod_perl, and I believe it would help the cause for mod_perl if linux 6.1 users could simply download an easy to use, drop-in replacement for the apparently broken mod_perl-1.21-2.i386.rpm
