Re: transaction Apache::DBI
Le jeu 13/11/2003 à 20:08, Perrin Harkins a écrit :
> On Thu, 2003-11-13 at 10:32, Christophe Musielak wrote:
> > My question is : is it safe to use transactions of multiple objects,
> > doing a commit or rollback at the end as i'm sure i will stay in the
> > same interpreter space and that no other user can ask for the same
> > database handle to do some stuff while i'm working?
>
> Yes. Database handles are not shared between interpreters.
Ok
>
> > btw, ApacheDBI is always returning me a handle with the default
> > parameters i used when issuing the connection ( {AutoCommit => 1} for
> > example), even if i changed the parameters with
> > local->{dbh}->{AutoCommit} = 0.
>
> Hmmm... Was I talking to you about this on Perlmonks?
Yes
>
> It sounds like maybe you don't understand what local() does, which is
> not surprising since hardly anyone does. Any change you make with
> local() only lasts for the current scope. If you change things without
> local(), it will change the cached handle permanently.
Thanks for your answer Perrin. I tried without local() too and i see
exactly the same result, ie each time i ask DBI via ApacheDBI for a
database handle, i get the handle with the same parameters i created the
handle with, not the ones i just modified, although i can see while
login it's the same handle.
To be clear, as my english not so good :
-
my $db = DBI->connect($dsn,$user, $password, { AutoCommit => 1,
RaiseError => 1 } )||
die "ERROR NO_CONNECTION_TO_POSTMASTER\n";
print "$db"."\n";
print "".$db->{AutoCommit}."\n";
$db->{AutoCommit} = 0;
print "".$db->{AutoCommit}."\n";
my $db2 = DBI->connect($dsn,$user, $password, { AutoCommit => 1,
RaiseError => 1 } )||
die "ERROR NO_CONNECTION_TO_POSTMASTER\n";
print "$db"."\n";
print "".$db->{AutoCommit}."\n";
-
And here is the result :
Database::Dbh = Apache::DBI::db=HASH(0x8f95d28)
Database::Dbh =1
Database::Dbh = # ok AutoCommit Off
Database::Dbh = Apache::DBI::db=HASH(0x8f95d28) # ok same handler
Database::Dbh =1 <<< AutoCommit back On !!
Is this a normal behave of Apache::DBI or am i missing something?
Thanks a lot for your help.
Christophe.
> - Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] segfault when generating graphs with GD::Graph under Embperl
Hi Guys!
Another day, another try...another segfault ;-(
(gdb) run -X
Starting program: /usr/sbin/httpd -X
Program received signal SIGSEGV, Segmentation fault.
0x00e89582 in ?? ()
(gdb)
(gdb)
(gdb) BT
#0 0x00e89582 in ?? ()
#1 0x006e8c44 in ?? ()
#2 0x0106 in ?? ()
#3 0x006b9aa6 in ?? ()
#4 0x00508940 in ?? ()
#5 0x09c59c74 in ?? ()
#6 0x41414141 in ?? ()
#7 0xbff90488 in ?? ()
#8 0x00440bdd in ?? ()
#9 0x41414141 in ?? ()
#10 0x0968542c in ?? ()
#11 0x006e89e4 in ?? ()
#12 0x09c59c74 in ?? ()
#13 0x09b89b40 in ?? ()
#14 0xbff904a8 in ?? ()
#15 0x006c7493 in ?? ()
#16 0x09c59c74 in ?? ()
#17 0x00d3a410 in ?? ()
#18 0x0968542c in ?? ()
I rewrote the smaller one of the graph-generating epl's as perl code.
This is how i call the embperl page:
[-
Execute('../call/flow-graph.epl', "$date", "src");
Execute('../call/flow-graph.epl', "$date", "dest");
-]
And this the mod_perl way:
[-
Execute({inputfile => '../call/flow-graph.pl', syntax => 'Perl', param =>
["$date", 'src']});
Execute({inputfile => '../call/flow-graph.pl', syntax => 'Perl', param =>
["$date", 'dest']});
-]
Both lead to a segfault.
BUT:
If i call flow-graph.pl directly from the browser the page works!!!
@Martien: I forwarded the mail to you too because maybe you know something about
the problem as it occurs only with your GD::Graph module.
Thanks, Alex
Von: Stas Bekman <[EMAIL PROTECTED]> am 13.11.2003 22:41
An: Gerald Richter <[EMAIL PROTECTED]>
Kopie:Alexander Hartmaier/DEBIS/EDVG/[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
Thema:Re: Antwort: Re: Antwort: Re: [mp2] segfault when generating graphs
with GD::Graph under Embperl
Gerald Richter wrote:
> Hi Stas,
>
>>There is an easy way to work around it. Run the program under gdb and
>>it'll remember the trace even the memory (frames) gets corrupted.
>>
>>gdb /path/to/httpd
>>gdb> run -X
>>issue a request here and gdb will tell you that you've got a segfault
>> bt
>>will give you the trace.
>>
>
>
> This is excatly what we have done and which gives the above trace with does
> not contain any usefull informations ...
Sorry, Gerald. I've missed that detail then.
In which case you need to try to manually step through guessing some
breakpoints where things could go wrong.
__
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
*2*
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] segfault when generating graphs with GD::Graph under Embperl
> > If i call flow-graph.pl directly from the browser the page works!!! > How is the file run when you call it directly, as CGI or via Apache::Registry ? Gerald -- Gerald Richter ecos electronic communication services gmbh IT-Securitylösungen * dynamische Webapplikationen * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice: +49 6133 939-122 WWW:http://www.ecos.de/ Fax: +49 6133 939-333 -- | | ECOS BB-5000 Firewall- und IT-Security Appliance: www.bb-5000.info | +- -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] segfault when generating graphs with GD::Graph under Embperl
snip from httpd.conf: SetHandler perl-script PerlResponseHandler ModPerl::Registry PerlOptions +ParseHeaders Options +ExecCGI Yours sincerly Alexander Hartmaier T-Systems T-Systems Austria TCS/Network Monitoring & Security Specialist address: Hofmühlgasse 3-5, 1060 Wien telephone: +43 (0)57057 - 4320 fax: +43 (0)57057 - 4152 mobile: +43 (0)676 8642 - 4320 mail: [EMAIL PROTECTED] Internet: http://www.t-systems.at Von: Gerald Richter <[EMAIL PROTECTED]> am 14.11.2003 12:38 An: Alexander Hartmaier/DEBIS/EDVG/[EMAIL PROTECTED], Stas Bekman <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Kopie:[EMAIL PROTECTED], [EMAIL PROTECTED] Thema:Re: [mp2] segfault when generating graphs with GD::Graph under Embperl > > If i call flow-graph.pl directly from the browser the page works!!! > How is the file run when you call it directly, as CGI or via Apache::Registry ? Gerald -- Gerald Richter ecos electronic communication services gmbh IT-Securitylösungen * dynamische Webapplikationen * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice: +49 6133 939-122 WWW:http://www.ecos.de/ Fax: +49 6133 939-333 -- | | ECOS BB-5000 Firewall- und IT-Security Appliance: www.bb-5000.info | +- *2* -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] segfault when generating graphs with GD::Graph under Embperl
Alexander Hartmaier wrote: > snip from httpd.conf: > > > SetHandler perl-script > PerlResponseHandler ModPerl::Registry > PerlOptions +ParseHeaders > Options +ExecCGI > > So it seems to be only happening when Embperl is involved. Any chance that you can send me a small test case of your GD script, that I can run and debug here? Gerald > Yours sincerly > Alexander Hartmaier > > T-Systems > > T-Systems Austria > TCS/Network Monitoring & Security Specialist > address: Hofmühlgasse 3-5, 1060 Wien > telephone: +43 (0)57057 - 4320 > fax: +43 (0)57057 - 4152 > mobile: +43 (0)676 8642 - 4320 > mail: [EMAIL PROTECTED] > Internet: http://www.t-systems.at > > > > > Von: Gerald Richter <[EMAIL PROTECTED]> am 14.11.2003 12:38 > > > > An: Alexander Hartmaier/DEBIS/EDVG/[EMAIL PROTECTED], Stas Bekman > <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Kopie:[EMAIL PROTECTED], [EMAIL PROTECTED] > > Thema:Re: [mp2] segfault when generating graphs with GD::Graph > under Embperl > >> >> If i call flow-graph.pl directly from the browser the page works!!! >> > How is the file run when you call it directly, as CGI or via > Apache::Registry ? > > Gerald > > -- > Gerald Richter ecos electronic communication services gmbh > IT-Securitylösungen * dynamische Webapplikationen * Consulting > > Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz > E-Mail: [EMAIL PROTECTED] Voice: +49 6133 939-122 > WWW:http://www.ecos.de/ Fax: +49 6133 939-333 > -- >> >> ECOS BB-5000 Firewall- und IT-Security Appliance: www.bb-5000.info >> > +- > > *2* -- Gerald Richter ecos electronic communication services gmbh IT-Securitylösungen * dynamische Webapplikationen * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice: +49 6133 939-122 WWW:http://www.ecos.de/ Fax: +49 6133 939-333 -- | | ECOS BB-5000 Firewall- und IT-Security Appliance: www.bb-5000.info | +- -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: transaction Apache::DBI
On Fri, 2003-11-14 at 02:50, Christophe Musielak wrote:
> my $db = DBI->connect($dsn,$user, $password, { AutoCommit => 1,
> RaiseError => 1 } )||
> die "ERROR NO_CONNECTION_TO_POSTMASTER\n";
>
> print "$db"."\n";
>
> print "".$db->{AutoCommit}."\n";
>
> $db->{AutoCommit} = 0;
>
> print "".$db->{AutoCommit}."\n";
>
> my $db2 = DBI->connect($dsn,$user, $password, { AutoCommit => 1,
> RaiseError => 1 } )||
> die "ERROR NO_CONNECTION_TO_POSTMASTER\n";
>
> print "$db"."\n";
> print "".$db->{AutoCommit}."\n";
>
> -
>
> And here is the result :
>
> Database::Dbh = Apache::DBI::db=HASH(0x8f95d28)
> Database::Dbh =1
> Database::Dbh = # ok AutoCommit Off
> Database::Dbh = Apache::DBI::db=HASH(0x8f95d28) # ok same handler
> Database::Dbh =1 <<< AutoCommit back On !!
Thanks for the example, now I understand the issue and I can reproduce
it on my system.
> Is this a normal behave of Apache::DBI or am i missing something?
I don't think this is intentional, and it certainly seems like incorrect
behavior. DBI does some very strange things internally with TIE in
order to allow you to set these attributes, and I think that is getting
confused somehow. I'm not an expert on DBI internals, so I don't know
exactly where the problem is. You should probably try writing to the
dbi-users list. I'll try to look into it a little more later if I have
some time.
If you do find an answer, please post it to this list.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: PATCH perl_reference.pod "Remedies for Inner Subroutines"
Stas Bekman <[EMAIL PROTECTED]> writes:
> Brian McCauley wrote:
>
> > Here's a _very_ rough first cut at perl_reference.pod. I haven't even
> > proof-read it yet so it's probably got spelling a and grammar errors
> > but I just want to be sure I'm going in the right direction.
>
> Thanks Brian. A few comments:
>
> [...]
> > - #!/usr/bin/perl -w
> > + #!/usr/bin/perl
> > use strict;
> > + use warnings;
>
> But that won't work with perl < 5.6.
This is example code being used to illustrate a point. It is more
appropriate therefore (IMHO) that it reflect best current practice
than that it maintain backward compatability. Anyone still using Perl
< 5.6 must be used to seeing "use warnings" all over the place and
know that they need to remove it on their system. Unless, of course,
they are living in total isolation - in which case they'll never see
this document so the point is moot anyhow.
> [...]
> > +The simplest of the workarounds is to use package-scoped variables,
> > +declared using C or, on older versions of Perl, the C
> > +pragma. Note that whereas using C declaration also implicitly
> > +initializes variables to undefined the C declaration does not,
> > +and so you may need to add explicit initialisation.
> > multirun1.pl
> > - ---
> > - #!/usr/bin/perl -w
> > +
> > + #!/usr/bin/perl
> > use strict;
> > - use vars qw($counter);
> > -
> > + use warnings; +
> >for (1..3){
> > print "run: [time $_]\n";
> > run();
> > @@ -946,7 +953,7 @@
> > sub run {
> >-$counter = 0;
> > +our $counter = 0;
>
> I think it would be more clear if all are declared at the top of the
> file,
Declaring variables at the top of the file is, IMNSHO, a bad
programming habit that should be discouraged. Variables' declaration
and initialisation should be kept together wherever possible. It
seems more natural. It aids readibility. It aids maintainability. I
have collegues who program in the "declarations go at the top" style.
Their programs almost invariably declare variables that are never then
used.
> just where the 'use vars' declaration was.
Remember that you are looking at the diff file so it seems to you that
I've moved the declaration. The end-user reader of perl_reference.pod
is not looking at the diff file. They are comparing multirun.pl and
multirun1.pl. So from their point of view, by simply replacing "my"
with "our" I'm keeping the declaration in the same place. If we were
to move the declaration away from the initialisation then I think we'd
have to explain why we did it. And since I think it's a bad idea I
couldn't do that.
> [...]
> >multirun2.pl
> > - ---
> > +
> >#!/usr/bin/perl -w
> > use strict;
> > @@ -993,14 +1023,14 @@
> > sub run {
> >-$main::counter = 0;
> > +$::counter = 0;
>
> what's the gain in doing this? The two are identical and for
> unexperienced perl users $::counter will look totally alien.
That, of course, would depend on the nature of their (in)experience to
date :-). If they have always seen explicit access to variables in the
root namepace written as $::counter then it is the use of the alias
$main::counter that will look totally alien.
However, given that I go on to refer to root namespace as 'main::'
later on, I suppose it makes sense to be consistant and revert to
using the alias throughout.
> The rest looks good, sans spelling ;)
I'll try to fix that now.
Combined patch follows.
--- perl_reference.pod.orig Thu Aug 14 18:11:11 2003
+++ perl_reference.pod Fri Nov 14 17:39:20 2003
@@ -863,16 +863,17 @@
problem, Perl will always alert you.
Given that you have a script that has this problem, what are the ways
-to solve it? There are many of them and we will discuss some of them
-here.
+to solve it? There have been many suggested in the past, and we
+discuss some of them here.
We will use the following code to show the different solutions.
multirun.pl
---
- #!/usr/bin/perl -w
+ #!/usr/bin/perl
use strict;
+ use warnings;
for (1..3){
print "run: [time $_]\n";
@@ -925,20 +926,27 @@
Counter is equal to 5 !
Counter is equal to 6 !
-Obviously, the C<$counter> variable is not reinitialized on each
-execution of run(). It retains its value from the previous execution,
-and sub increment_counter() increments that.
-
-One of the workarounds is to use globally declared variables, with the
-C pragma.
+Apparently, the C<$counter> variable is not reinitialized on each
+execution of run(), it retains its value from the previous execution,
+and increment_counter() increments that. Actually that is not quite
+what happens. On each execution of run() a new C<$counter> variable
+is initialized to zero but increment_counter() remains bound to the
+C<$counter> variable from the first call to run().
+
+The simplest of the work-rounds is to use package-scoped variables.
+These can be declared us
How to get Perl to use a new Apache install for Module compiling
I seem to be running into a problem i figure lots of other people must be running into, but i can't find any reference to it anywhere. Or I am just not very good at searching. Here's the issue: - Redhat installed apache 2.0 on install - I configure and install 1.3.27 and build it into /usr/local/apache-1.3.27 - I then want to build things like Apache::Request, Apache::Test, etc. which seem to require apache headers and also fire up apache during the test phase. - But at this point it always seems to use the original 2.0 install to test and compile against I can get it working, it seems by specifying --sbindir and clobbering the original install. But i'd rather not so i can later install a new version of apache and not have to clobber the known good before running the new one for a while. thanks, arne -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Question about headers and Apache::Filter
Hello I had been trying to use Apache::OutputChain Apache::SSIChain Apache::Registry to allow me to use SSI in the output of my mod_perl programs. The ssi content always wound up at the top of the output. After reading the mailing list it seemed that Apache::RegistryFilter Apache::SSI was the way to go. Well it works great except that the header type is always text/plain so I get the HTML source instead of the rendered page. My setup is as follows PerlModule Apache::DBI PerlModule Apache::Registry PerlModule Apache::SSI PerlModule Apache::FakeSSI PerlModule Apache::Filter PerlModule Apache::RegistryFilter SetHandler perl-script Options +ExecCGI PerlSetVar Filter On PerlHandler Apache::RegistryFilter Apache::SSI #also tried Apache::FakeSSI It seems that PerlSendHeader On has no effect when you are using Apache::RegistryFilter, how can I get the proper headed type sent? Thanks, Robert -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: How to get Perl to use a new Apache install for Module compiling
Arne Claassen <[EMAIL PROTECTED]> writes: > I seem to be running into a problem i figure lots of other people must > be running into, but i can't find any reference to it anywhere. Or I > am just not very good at searching. > > Here's the issue: > > - Redhat installed apache 2.0 on install > - I configure and install 1.3.27 and build it into > /usr/local/apache-1.3.27 > - I then want to build things like Apache::Request, Apache::Test, etc. > which seem to require apache headers and also fire up apache during > the test phase. > - But at this point it always seems to use the original 2.0 install to > test and compile against > > I can get it working, it seems by specifying --sbindir and clobbering > the original install. But i'd rather not so i can later install a new > version of apache and not have to clobber the known good before > running the new one for a while. Edit scripts and build rpm packages in order to keep everything clean. True, it is not so easy... See specific modules documentation and for rpm use cpanflute2 or cpan2rpm... -- Arnaud -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
RH80/mod-perl/httpd2
hello, everything i read refers to a setup different than mine. my apache is not in /usr/local/apache2...i installed from rpm...with that being said...should I install from source to be able to follow the fix instructions in the posts I am reading. I am getting this error: Can't locate object method "register_cleanup" via package "Apache::RequestRec" at /usr/lib/perl5/5.8.0/CGI.pm line 270. , /usr/lib/perl5/site_perl/5.8.0/Apache/ASP.pm line 1514 C. L. Hammond Engineer NAVSYS Corporation (719)481-4877 x 169 [EMAIL PROTECTED] ** ** -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: RH80/mod-perl/httpd2
Christopher Hammond wrote: hello, everything i read refers to a setup different than mine. my apache is not in /usr/local/apache2...i installed from rpm...with that being said...should I install from source to be able to follow the fix instructions in the posts I am reading. I am getting this error: Can't locate object method "register_cleanup" via package "Apache::RequestRec" at /usr/lib/perl5/5.8.0/CGI.pm line 270. , /usr/lib/perl5/site_perl/5.8.0/Apache/ASP.pm line 1514 % lookup register_cleanup 'register_cleanup' is not a part of the mod_perl 2.0 API use 'cleanup_register' instead. To use method 'cleanup_register' add: use APR::Pool (); http://perl.apache.org/docs/2.0/api/ModPerl/MethodLookup.html#Command_Line_Lookups Must be an old CGI.pm. Try with the latest CGI.pm. In the future report bugs following these guidelines: http://perl.apache.org/bugs/ __ 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 -"undefined symbol" in error_log - HOWTO
Here's a very rough draft of what do do if the error_log includes any "undefined symbol" errors. It's mostly based on Stas' advice for when i had this problem last week. If the error_log includes any "undefined symbol" errors. Assumptions: You ran make test and got errors, and you looked in the error_log file (t/logs/error_log) and saw one or more "undefined symbol" errors, e.g. undefined symbol: apr_table_compress Step 1: --- From the source directory (same place you ran "make test") run: ldd blib/arch/auto/APR/APR.so | grep apr- META: ldd is not available on all platforms, e.g. not on Darwin/OS X You you should get a full path, for example: libapr-0.so.0 => /usr/local/apache2/lib/libapr-0.so.0 (0x40003000) or libapr-0.so.0 => /some/path/to/apache/lib/libapr-0.so.0 (0x40003000) or something like that. It's that full path to libapr-0.so.0 that you want. Step 2: --- Do: nm /path/to/your/libapr-0.so.0 | grep table_compress for example: nm /usr/local/apache2/lib/libapr-0.so.0 | grep table_compress Note that the "grep table_compress" is only an example, the exact string you are looking for is the name of the "undefined symbol" from the error_log. So, if you got "undefined symbol: apr_holy_grail" then you would do nm /usr/local/apache2/lib/libapr-0.so.0 | grep holy_grail You should get something like this: d010 T apr_table_compress Step 3: --- Now, let's see what shared libraries your apache binary has. So, if in step 1 you got "/usr/local/apache2/lib/libapr-0.so.0" then you will do: ldd /usr/local/apache2/bin/httpd if in step 1 you got "/foo/bar/apache/lib/libapr-0.so.0" then you do: ldd /foo/bar/apache/bin/httpd The output should look something like this: libssl.so.2 => /lib/libssl.so.2 (0x40023000) libcrypto.so.2 => /lib/libcrypto.so.2 (0x40054000) libaprutil-0.so.0 => /usr/local/apache2/lib/libaprutil-0.so.0 (0x40128000) libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x4013c000) libdb-4.0.so => /lib/libdb-4.0.so (0x40143000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0x401eb000) libapr-0.so.0 => /usr/local/apache2/lib/libapr-0.so.0 (0x4020b000) librt.so.1 => /lib/librt.so.1 (0x40228000) libm.so.6 => /lib/i686/libm.so.6 (0x4023a000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x4025c000) libnsl.so.1 => /lib/libnsl.so.1 (0x40289000) libdl.so.2 => /lib/libdl.so.2 (0x4029f000) libpthread.so.0 => /lib/i686/libpthread.so.0 (0x402a2000) libc.so.6 => /lib/i686/libc.so.6 (0x4200) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) Those are name=>value pairs showing the shared libraries required by the httpd binary. Take note of the value for libapr-0.so.0 and compare it to what you got in step 1. They should be the same, if not, then mod_perl was compiled pointing to the wrong Apache installation. You should run "make clean" and then perl Makefile.pl MP_APACHE_CONFIG=/path/to/apache/bin/apr-config using the correct path for the Apache installation. Step 4: --- You should also search for extra copies of libapr-0.so.0 If you find one in /usr/lib or /usr/local/lib that will explain the problem. Most likely you have an old pre-installed apr package which gets loaded before the copy you found in step 1. On most Linux (and Mac OS X) machines you can do a fast search with: locate libapr-0.so.0 which searches a database of files on your machine. The "locate" database isn't always up-to-date so a slower, more comprehensive search can be run (as root if possible): find / -name "libapr-0.so.0*" or find /usr/local -name "libapr-0.so.0*" You might get output like this: /usr/local/apache2.0.47/lib/libapr-0.so.0.9.4 /usr/local/apache2.0.47/lib/libapr-0.so.0 /usr/local/apache2.0.45/lib/libapr-0.so.0.9.3 /usr/local/apache2.0.45/lib/libapr-0.so.0 in which case you would want to make sure that you are configuring and compiling mod_perl with the latest version of apache, for example using the above output, you would do: perl Makefile.PL MP_AP_CONFIG=/usr/local/apache2.0.47 make make test -- -- Matisse Enzer Doodlelab Inc. 415-925-5294 ext. 212 (office) 415-225-6703 (mobile) -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: mp2 -"undefined symbol" in error_log - HOWTO
Matisse Enzer wrote: Here's a very rough draft of what do do if the error_log includes any "undefined symbol" errors. It's mostly based on Stas' advice for when i had this problem last week. Just perfect, Matisse. I wish my rough drafts were all like this. I've committed it after podifying it and doing a few minor tweaks (mainly formatting). Here it is: http://perl.apache.org/docs/2.0/user/troubleshooting/troubleshooting.html#undefined_symbol__apr_table_compress Muchas gracias, keep those patches coming __ 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: PATCH perl_reference.pod "Remedies for Inner Subroutines"
Brian McCauley wrote:
Stas Bekman <[EMAIL PROTECTED]> writes:
Brian McCauley wrote:
Here's a _very_ rough first cut at perl_reference.pod. I haven't even
proof-read it yet so it's probably got spelling a and grammar errors
but I just want to be sure I'm going in the right direction.
Thanks Brian. A few comments:
[...]
- #!/usr/bin/perl -w
+ #!/usr/bin/perl
use strict;
+ use warnings;
But that won't work with perl < 5.6.
This is example code being used to illustrate a point. It is more
appropriate therefore (IMHO) that it reflect best current practice
than that it maintain backward compatability. Anyone still using Perl
< 5.6 must be used to seeing "use warnings" all over the place and
know that they need to remove it on their system. Unless, of course,
they are living in total isolation - in which case they'll never see
this document so the point is moot anyhow.
Agreed.
+The simplest of the workarounds is to use package-scoped variables,
+declared using C or, on older versions of Perl, the C
+pragma. Note that whereas using C declaration also implicitly
+initializes variables to undefined the C declaration does not,
+and so you may need to add explicit initialisation.
multirun1.pl
- ---
- #!/usr/bin/perl -w
+
+ #!/usr/bin/perl
use strict;
- use vars qw($counter);
-
+ use warnings; +
for (1..3){
print "run: [time $_]\n";
run();
@@ -946,7 +953,7 @@
sub run {
-$counter = 0;
+our $counter = 0;
I think it would be more clear if all are declared at the top of the
file,
Declaring variables at the top of the file is, IMNSHO, a bad
programming habit that should be discouraged. Variables' declaration
and initialisation should be kept together wherever possible. It
seems more natural. It aids readibility. It aids maintainability. I
have collegues who program in the "declarations go at the top" style.
Their programs almost invariably declare variables that are never then
used.
Sorry I've missed the word "globals" while typing, so it should have read:
I think it would be more clear if all globals are declared at the top of the
file,
You are talking about the locality rule, which I perfectly agree with when it
comes to scoped variables.
However when it comes to globals I tend to disagree with you. globals should
be all declared together at the top of the file/package so that it's easy to
learn what variables are globals and not scan the code (perhaps thousands of
lines trying to spot those globals definition in the code where they are used.
Consider:
% perl -le ' {our $x = 5;} print $x'
5
Now move that our definition hundreds of lines into the code, are going to
spot it?
Granted, using 'use strict':
% perl -le ' use strict; use warnings; {our $x = 5;} print $x'
Variable "$x" is not imported at -e line 1.
Global symbol "$x" requires explicit package name at -e line 1.
Execution of -e aborted due to compilation errors.
this potential error of our() scoped variable affecting some other global with
the same name, won't creep in. But unfortunately many don't use 'use strict'.
Of course you will say that the example does use 'use strict' and therefore
this global definition is scoped well and defined where it should be. And
you'd be right. In which case I've no objections.
/me is still trying to wrap his head around our()'s subtleties.
just where the 'use vars' declaration was.
Remember that you are looking at the diff file so it seems to you that
I've moved the declaration. The end-user reader of perl_reference.pod
is not looking at the diff file. They are comparing multirun.pl and
multirun1.pl. So from their point of view, by simply replacing "my"
with "our" I'm keeping the declaration in the same place. If we were
to move the declaration away from the initialisation then I think we'd
have to explain why we did it. And since I think it's a bad idea I
couldn't do that.
Agreed.
[...]
multirun2.pl
- ---
+
#!/usr/bin/perl -w
use strict;
@@ -993,14 +1023,14 @@
sub run {
-$main::counter = 0;
+$::counter = 0;
what's the gain in doing this? The two are identical and for
unexperienced perl users $::counter will look totally alien.
That, of course, would depend on the nature of their (in)experience to
date :-). If they have always seen explicit access to variables in the
root namepace written as $::counter then it is the use of the alias
$main::counter that will look totally alien.
I guess I have hardly ever seen code that uses $::, and still strikes me odd.
But that's just my personal (in)experience as you put it.
However, given that I go on to refer to root namespace as 'main::'
later on, I suppose it makes sense to be consistant and revert to
using the alias throughout.
Perfect.
The rest looks good, sans spelling ;)
I'll try to fix that now.
Combined patch follows.
Perfect. Both are now committed and will appear online within the next 6 hours.
Thanks a lot,
