RE: AxKit Shutdown
Matt, this is exactly the sort of thing that I am telling is obscuring the access to AxKit. OK, you have the domain name problems because you chose to first shut the old one down, and then to put the new one up, not the other way around. Whatever it is, right now people have to go to the modperl list for this thread to learn how to get to the AxKit.org site, which currently is essentially part of the overall axkit documentation. AxKit is available for free, and hence I am not expecting perfect documentation in the man pages, and I understand the need to go to the sources *occasionally* for advanced tasks, but if you say in the mans every other sentence for the new users to go to axkit.org, and axkit.org is not there, that's tough. As long as a very simple change can eliminate this problem, and give you more excuses for further delaying the doc polishing :) I mean, can you PLEASE release a new AxKit, a minor update, with basically just the root manpage and README file updated, to say smth like: Currently, AxKit.org is experiencing DNS hosting problems. If you are unable to access the site, please add the following to your /etc/hosts: 217.158.50.178 axkit.org Please stay tuned to ... [whatever you prefer here - maybe, axkit-users? maybe, a new list for moderate volume axkit announcements for updates on the new releases and problems like this?] in order to know when this kludge can be removed... Vassilii -Original Message- From: Matt Sergeant [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 06, 2001 4:43 AM To: 'Patrick' Cc: [EMAIL PROTECTED] Subject: RE: AxKit Shutdown -Original Message- From: Patrick [mailto:[EMAIL PROTECTED]] On Fri, Nov 02, 2001 at 09:48:52AM -, Matt Sergeant took time to write: This is sad indeed. Once everything is up and running again I'll write a complete document of the nightmares that getting it back up again has been and post it to the mod_perl and axkit lists. Meanwhile you can get there at http://217.158.50.178/ - the mailing list links are back to axkit.org, so you need to edit the links with the IP address again. Sorry for the downtime, it's *really* not my fault. Blame NetSol, and Demon, and BT, and ClaraNet (get the idea yet?). This is understandable. However I'm sure that some people may like to host mirrors for you. I already offered you in private email to be a secondary NS for your domain names so that network outages have less consequences. It still stands. As I've said to everyone of these offers: mirroring isn't the problem right now - the web site is up at http://217.158.50.178/, it just doesn't have the domain name. We don't really get the sort of traffic that requires a mirror for bandwidth problems, and I've yet to get a complaint that it's down. Thanks though. Matt. _ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service.
RE: Shutdown
Hi Matt, do you have any news on planned re-appearance of current axkit docs and mailing list archives online? The net people memory is short, if you don't come back noone will know what AxKit is :-( Or did you abandon it in favor of smth better? Vassilii -Original Message- From: Matt Sergeant [mailto:[EMAIL PROTECTED]] Sent: Monday, August 13, 2001 12:29 PM To: AxKit Users Mailing List Cc: [EMAIL PROTECTED] Subject: Shutdown Tomorrow is my shutdown date for axkit.org, take23.org, axkit.com, and *.sergeant.org. It will happen at about 0800 GMT. I will hopefully be back online in about 7 to 10 days when my DSL gets installed at the new house (yay!). Unfortunately the switch over to apache.org did not happen in time, so the server, mailing list, and cvs will be unavailable during this time period. However, I have asked Kip Hampton to mirror the download directory for me, and that will be available somewhere soon when he posts the URL here. Please nobody else try and mirror it, as the bandwidth used may prevent people from getting this email :-)
Perl incompat. with apache/mod_perl upgrade
When I upgraded from
Solaris Apache/1.3.14 (Unix) mod_perl/1.24_01
to
Solaris Apache/1.3.17 (Unix) mod_perl/1.25
the following code in my debugging httpd.conf broke:
Perl
sub WWW_DIR () { $ENV{'HOME'} . '/www' ; } # this sub will persist to next
Perl
... more code, using WWW_DIR sometimes
/Perl
.. more plain apache conf stuff here
Perl
$AxCacheDir = WWW_DIR . '/htdocs/x/cache';
/Perl
While this worked before, it now generates an undef sub called at the second
Perl
section. Redefining it there again works, but emits strange prototype
mismatch stuff
at the 2nd Perl calling of the routine.
To restore the old behavior I had to define it again without the brackets
(the args
prototype) at the 2nd section.
Was this change intentionally done (why?!), or is it a by-product of some
other code advances?
What is the correct way of passing Perl stuff from one Perl section to
another?
Vassilii
RE: Perl incompat. with apache/mod_perl upgrade
Read it. It still doesn't address my questions
- why this stopped working with
the new mod_perl+apache. From the docs, rather, I'd expect a
routine or a variable defined in one Perl section persist to the other.
While I can't use global vars (they try to get tied to the non-existing
config. params), and lexicals remain scoped within the same Perl
section, I had to use a sub before, which I was able to access in
the other Perl section. Now I am not. The docs say, however, I
am eval-ed in Apache::ReadConfig - o.k., so the subs should get
defined there and then remain there, as long as the same config
file is read?
I didn't want to use too heavy stuff (PerlSetVar or the module recently
discussed here - was it Apache::Storage?)
because I just wanted some shortcuts for the scope of the .conf file
only. It was better to cut-n-paste them in the worst case than carve
them in Apache brains, stealing the precious memory
from mod_perl :-).
-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 12, 2001 8:39 PM
To: Khachaturov, Vassilii
Cc: '[EMAIL PROTECTED]'
Subject: Re: Perl incompat. with apache/mod_perl upgrade
...
Perl
sub WWW_DIR () { $ENV{'HOME'} . '/www' ; } # this sub will persist to next
Perl
... more code, using WWW_DIR sometimes
/Perl
.. more plain apache conf stuff here
Perl
$AxCacheDir = WWW_DIR . '/htdocs/x/cache';
/Perl
While this worked before, it now generates an undef sub called at the
second
...
Was this change intentionally done (why?!), or is it a by-product of some
other code advances?
What is the correct way of passing Perl stuff from one Perl section to
another?
Please read
http://perl.apache.org/guide/config.html#Apache_Configuration_in_Perl
and you will understand how CPerl sections work.
I also don't understand why are you trying to use sub to define a
variable, which is pretty useless, since you use it only during
configuration. Also use the constant pragma.
RE: Perl incompat. with apache/mod_perl upgrade
And, of course, I am using Stas' patent with 'use constant' now... -Original Message- From: Khachaturov, Vassilii Sent: Tuesday, March 13, 2001 2:19 AM To: 'Steve Leibel' Cc: [EMAIL PROTECTED] Subject: RE: Perl incompat. with apache/mod_perl upgrade I've been planning on doing this tomorrow anyhow (w/o any hope), just have to get past some presentation on the existing server with minimal breathing around it. Now, you are the one who gives me a real basis for that hope! Thanks for the tip. Vassilii
RE: HTTP_REFERRER and Mod_perl
Please keep in mind that what you describe is a behaviour of one particular user agent. Some UAs just never send referer for anonymity. (Sometimes proxy will do that for them). Some do it for links from a web page, but not from a file:// URL. Some don't care for the URI scheme, and you get referer's from one's bookmarks on the disk. So, I think, the moral of the story is that basing your site logic on smth that requires particular way of referer tracking is not the best option. You probably want to use some means of session control if you want to make it more standard/portable (there are many ways of doing it - discussed lots of times around here). I agree, however, that if you are aiming at some local community and you are pretty sure about their least common denominator of referer-sending behaviour, the CPU wasted at your server will be less if you check the referer. I personally use referer only for xrefs validation/stats purposes. Vassilii http://www.tarunz.org/~vassilii -Original Message- From: Stef Telford [mailto:[EMAIL PROTECTED]] Sent: Monday, January 15, 2001 2:36 PM To: siberian Cc: [EMAIL PROTECTED] Subject: Re: HTTP_REFERRER and Mod_perl When i link, they do. So i guess the moral of the story here is that meta tag redirects DONT set the REFERER variable at all.
RE: Perl Script Source Code...
perldoc -q hide
RE: mod-perl on Solaris 2.6
Did you rebuild Perl since then? -Original Message- From: Siddhartha Jain [mailto:[EMAIL PROTECTED]] Sent: Monday, January 08, 2001 1:38 PM To: [EMAIL PROTECTED] Subject: Re: mod-perl on Solaris 2.6 oh! Sorry, i didn't mention but i have already applied all the latest Sun recommended patches on the machine. Now what?
RE: [OT]Problems with `use locale`
Did you try perlfaq - it has a couple of questions on locales. To start off, make sure your Perl has locale support in it: open your perl's Config.pm (it's /usr/local/lib/perl5/5.6.0/sun4-solaris/Config.pm on my system, do 'locate Config.pm' to find one on yours). Lines with "locale" there should have "define" in them, e.g. d_setlocale='define'. (Don't just change it if it's undef, rather, have your Perl reconfigured rebuilt appropriately). HTH, Vassilii -Original Message- From: martin langhoff [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 20, 2000 12:39 PM To: [EMAIL PROTECTED] Subject: [OT]Problems with `use locale` Dealing with Spanish as we are, we always have problems with regexp, uc() and lc(). I've found that on my dev box, just adding `use locale` at least uc() and lc() would work allright (meaning ñ got changed into Ñ properly). Now I've built a customer's machine with a newer distro and my uc() is broken where it was working. The devbox has RHLinux 6.1 and perl 5.005_03-6 The customer's box has RHLinux 6.2 and perl 5.005_03-10
RE: Trouble with AxKit at runtime - XML parsing stage
I take your answer as a polite confirmation that I am the only one to make that mistake :-) Well, this seems to be the case. Now that I know the problem cause, this *is* obvious. Still, the guide doesn't clear things IMHO for one under the same weird false assumption that I had: "but the parent does not exit. Instead, the parent re-reads its configuration files, spawns a new set of child processes and continues to serve requests. It is almost equivalent to stopping and then restarting the server. " It seems a subtle point indeed - that although the libperl.so is external, it has already been mapped into the core back at the runtime loader stage, and will never be reloaded. Until I asked myself this question in this form (what exactly happens with the apache core and why isn't the module reloaded?) I didn't get it. I wonder why I was so sure that apache re-exec's itself. I am sure I saw it in some public domain server after our homegrown webserver implementation had done it that way, some 6 years ago. Was it cern httpd then, rather than ncsa/apache? Well, I could also notice there is no "-listen-fd 4" or smth. argument in the respawned httpd process cmdline, to tell the restarting process where to take the listening socket... I like this technique because it ensures there is no resource leak (other than, possibly, forgotten open fds) on restart. Do you know if really many people suffer from the memory leaks you mention at the link you gave? Should I patch apache so it has such restart semantics in addition to (as another sighandler? configurable?)/instead the current HUP behaviour? I mean, will such patch be really useful for someone? Vassilii -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Friday, December 15, 2000 11:50 AM To: Khachaturov, Vassilii Cc: '[EMAIL PROTECTED]' Subject: RE: Trouble with AxKit at runtime - XML parsing stage Stas: maybe you could add a small section to your Guide elaborating on dependencies of things and what has to be remade when things are upgraded? (Or I am the only one to make such stupid mistake?) Well, it's documentated: http://perl.apache.org/guide/control.html#Restarting_Techniques Of course you cannot send a process the HUP signal and expect it to fully stop and re-start, unless you know that it does that. Isn't it obvious that when you upgrade some binary you should quit the program that's depending on it and restart it?
RE: Warning, Apache Version 1.3.0 required
This is a FAQ. Get mod_perl-1.24_01 where this is fixed. V. -Original Message- From: Richard [mailto:[EMAIL PROTECTED]] Sent: Friday, December 15, 2000 1:19 PM To: [EMAIL PROTECTED] Subject: Warning, Apache Version 1.3.0 required Ok, i've searched the archives and cannot find help for this problem there. I have compiled Apache v 1.3.14, without errors. I have then gone to compile mod_perl v1.24, below is my effort. The error/warning at the bottom states that i require Apache 1.3.0.
RE: Mod_perl tutorials
I believe there are structural differs for XML (I remember there was a perl script sgmldiff back 6 years ago!), which can be plugged into cvs environment for this type of files. If you want, I can dig further into it. Vassilii -Original Message- From: Matt Sergeant [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 14, 2000 8:17 AM To: Stas Bekman Cc: Randal L. Schwartz; mod_perl list Subject: Re: Mod_perl tutorials Even cvs diffs with XML won't be very easy to read, because there are too many tags. Thats a non-argument. XML can have as many or as few tags as POD.
Trouble with AxKit at runtime - XML parsing stage
Being seduced by the proud anouncements Matt made here, and seeing the axkit
and take23 sites,
I decided to play with AxKit myself.
I have installed AxKit according to the AxKit(3) manpage, and (I think)
configured apache to load it.
It uses sablotron 0.44 and the latest expat from sourceforge - 1.95.1 below
it.
All the dependent modules (like XML::Sablotron and XML::Expat) and AxKit
itself were reporting 100% test success.
CPAN reports all dependencies are up-to-date.
I have been unable, however, to render smth very basic with it, with just
XML+XSL test (I haven't yet come to XPath games).
0) Please pardon my q(2) in case of my XML/XSL fault - I have never used XSL
before today, and perhaps I omitted smth basic. My bg comes from DSSSL/SGML
and every time I look at XSL I am thinking first of an associated DSSSL
stuff, then locating the appropriate tag in the XSL spec, then writing XSL.
1) My 1st problem, however, is smth to deal with Apache-mod_perl-AxKit
interaction at configs read time.
It's a minor problem, and I have a workaround (see below), so you can just
skip down to (2). But I just hoped some of the mod_perl gurus around may
have some clue here.
I have tried 1st to place just
PerlModule AxKit
Location /x
AllowOverride All
/Location
into the apache httpd.conf,
and
# Install AxKit main parts
SetHandler perl-script
PerlHandler AxKit
# Setup style type mappings
AxAddStyleMap text/xsl Apache::AxKit::Language::Sablot
AxAddStyleMap application/x-xpathscript \
Apache::AxKit::Language::XPathScript
# Optionally set a hard coded cache directory
# make sure this is writable by the web server runtime user/group
AxCacheDir /usr/local/apache/htdocs/x/cache
into .htaccess under htdocs/x
It doesn't get to AxKit that way, despite AllowOverride All!
However, if I paste the contents of htdocs/x/.htaccess just before the
aforementioned /Location in the global conf file, everything is fine in
the sense that the perl handler gets installed. I didn't find anything
similar mentioned in Stas' guide - am I missing smth obvious, or has it smth
to do with AxKit in general or as installed here?
2) In the case of the worked around (1), here's what I get for a tiny test
case in the error log:
[AxKit] : handler called for /x/test.xml
[AxKit] : checking if we process this resource
[AxKit] : media: screen, preferred style: #default
[AxKit] : getting styles and external entities from the XML
[AxKit] : styles and external entities not cached - calling get_styles()
[AxKit] : get_styles: creating XML::Parser
[AxKit] : get_styles: calling
XML::Parser-parse('/usr/local/apache/htdocs/x/test.xml')
[Wed Dec 13 16:17:27 2000] [error] [client 172.24.223.142] [AxKit]
[UnCaught] Bizarre copy of ARRAY in aassign at
/usr/local/lib/perl5/5.6.0/Carp/Heavy.pm line 79.
[Wed Dec 13 16:17:27 2000] [error] [client 172.24.223.142] [AxKit]
[Backtrace] Bizarre copy of ARRAY in aassign at
/usr/local/lib/perl5/site_perl/5.6.0/Error.pm line 271
Error::subs::run_clauses('HASH(0x5c2c38)', 'Bizarre copy of ARRAY in
aassign at /usr/local/lib/perl5/5.6.0/C...', '', 'ARRAY(0x22a690)') called
at /usr/local/lib/perl5/site_perl/5.6.0/Error.pm line 386
Error::subs::try('CODE(0x1fd0dc)', 'HASH(0x5c2c38)') called at
/usr/local/lib/perl5/site_perl/5.6.0/sun4-solaris/AxKit.pm line 643
AxKit::handler('Apache=SCALAR(0x1fd0b8)') called at /dev/null line 0
require 0 called at /dev/null line 0
test.xml:
?xml version="1.0"?
?xml-stylesheet href="test.xsl" type="text/xsl"?
doc
titleThe quick brown fox jumps over the lazy dog./title
/doc
test.xsl:
?xml version="1.0"?
xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xsl:template match="doc"html
head
titlexsl:value-of select="title"//title
/head
body
h1xsl:value-of select="title"//h1
/body
/html/xsl:template
/xsl:stylesheet
I did check both for well-formedness with nsgmls, and both produce precicely
the ESIS I'd expect them to.
Can you please give some advice? An RTFM link would be appreciated as well.
Vassilii
-Original Message-
From: Khachaturov, Vassilli
Sent: Tuesday, December 12, 2000 10:08 AM
To: 'Matt Sergeant'
Subject: RE: Trouble installing AxKit/perl5.6.0/solaris5.6
Thanks, Matt!
It has been built out of the box.
I am going to play with it now...
V.
-Original Message-
From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
Sent: Monday, December 11, 2000 4:29 PM
To: Khachaturov, Vassilli
Subject: RE: Trouble installing AxKit/perl5.6.0/solaris5.6
On Mon, 11 Dec 2000, Khachaturov, Vassilli wrote:
I'm using Embedded Perl version v5.6.0 for Apache/1.3.14 (Unix)
mod_perl/1.24_01
AFAIU, this is not beta?
Yes, it is. Please use AxKit 1.1-pre.
RE: Trouble with AxKit at runtime - XML parsing stage
Well, it's kind of recent. I downloaded built it just a couple of weeks ago, 10656 -rw-r--r-- 1 root other5443601 Nov 30 15:40 /usr/local/perl/CPAN/sources/authors/id/G/GS/GSAR/perl-5.6.0.tar.gz and also cpan doesn't give me any reinstall recommendations for it, which I take as a sign for running the correct version. Can you point me to the patch (or just tell me its date on cpan) you've mentioned so I can check whether it made its way to my perl? Thanks for pointing to the axkit list, I'll subscribe it for sure. I was just unsure that the problem is axkit-specific (I can be missing smth with apache/mod_perl/XML/dependant modules as well), so I wanted people with relevant expertise but not interested in AxKit itself have a chance. V. -Original Message- From: Owen Stenseth [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 14, 2000 10:37 AM To: Khachaturov, Vassilii Cc: '[EMAIL PROTECTED]' Subject: Re: Trouble with AxKit at runtime - XML parsing stage I believe that the Bizzar copy of array problem is related to a bug in Perl 5.6 that was patched a while ago. Make sure you are running the latest version of perl5.6
RE: Trouble with AxKit at runtime - XML parsing stage
I have followed the advice given by
http://axkit.org/cgi-bin/ezmlm-cgi?3:mss:798:200012:gigblllnbhflgdoplaci
with similar symptoms, and just reinstalled 5.6.0 from ActiveState 620
source.
Then I reinstalled XML::Parser and AxKit forcibly.
Unfortunately, the error still persists. :-(((
Any other ideas? Any ideas on the minor problem (1) I mentioned earlier on
this thread?
(See this thread earlier at
http://forum.swarthmore.edu/epigone/modperl/spilwhudimp )
V.
-Original Message-
From: Owen Stenseth [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 14, 2000 10:37 AM
To: Khachaturov, Vassilii
Cc: '[EMAIL PROTECTED]'
Subject: Re: Trouble with AxKit at runtime - XML parsing stage
I believe that the Bizzar copy of array problem is related to a bug in
Perl 5.6 that was patched a while ago.
Make sure you are running the latest version of perl5.6
Also there is an AxKit users mailing list that you can post these
questions to:
[EMAIL PROTECTED]
--
Owen
[Snip]
[AxKit] : handler called for /x/test.xml
[AxKit] : checking if we process this resource
[AxKit] : media: screen, preferred style: #default
[AxKit] : getting styles and external entities from the XML
[AxKit] : styles and external entities not cached - calling get_styles()
[AxKit] : get_styles: creating XML::Parser
[AxKit] : get_styles: calling
XML::Parser-parse('/usr/local/apache/htdocs/x/test.xml')
[Wed Dec 13 16:17:27 2000] [error] [client 172.24.223.142] [AxKit]
[UnCaught] Bizarre copy of ARRAY in aassign at
/usr/local/lib/perl5/5.6.0/Carp/Heavy.pm line 79.
RE: Trouble with AxKit at runtime - XML parsing stage
http://bugs.perl.org/perlbug.cgi?req=querybody=Bizarre+copy seems to yield only one bug relevant to my particular error message case - http://bugs.perl.org/perlbug.cgi?req=bidbid=20001207.005range=6012format= H which is still open. No patch/patchid seen there. Did you mean this bug, or another? Is there some informal patch around? V. -Original Message- From: Dave Rolsky [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 14, 2000 12:28 PM To: Khachaturov, Vassilii; '[EMAIL PROTECTED]' Subject: Re: Trouble with AxKit at runtime - XML parsing stage On Thu, 14 Dec 2000, Owen Stenseth wrote: I believe that the Bizzar copy of array problem is related to a bug in Perl 5.6 that was patched a while ago. Make sure you are running the latest version of perl5.6 The latest version of 5.6 _is_ 5.6.0. The bizarre copy thing is fixed in CVS and 5.6.1 should incorporate this change. -dave /*== www.urth.org We await the New Sun ==*/
RE: Trouble with AxKit at runtime - XML parsing stage
I am sad to inform you that this patch is obsolete. The CLEAR_ARGARRAY
has evolved a lot since this message. It is now in 5.6.0
#define CLEAR_ARGARRAY(ary) \
STMT_START { \
AvMAX(ary) += AvARRAY(ary) - AvALLOC(ary); \
SvPVX(ary) = (char*)AvALLOC(ary);\
AvFILLp(ary) = -1; \
} STMT_END
without any conditioning on the USE_ITHREADS #define.
So, my problem is still hurting me.
(To catchup, see this thread earlier at
http://forum.swarthmore.edu/epigone/modperl/spilwhudimp )
V.
-Original Message-
From: Khachaturov, Vassilii
Sent: Thursday, December 14, 2000 4:58 PM
To: 'Dave Rolsky'; '[EMAIL PROTECTED]'
Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'
Subject: RE: Trouble with AxKit at runtime - XML parsing stage
Yes, indeed, it's mentioned on
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-06/msg00200.html
in GSAR's own message!
P5P: why is the bug mentioned in the Orig Msg below still open then?
Thanks a lot to all that helped or tried to! Sorry for missing this on the
AxKit FAQ earlier.
(I will be posting further if this doesn't close the problem in my AxKit
case. It's possible
as there are # of bizarre copy bugs in different contexts)
RE: Trouble with AxKit at runtime - XML parsing stage
Yes, indeed, it's mentioned on http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-06/msg00200.html in GSAR's own message! P5P: why is the bug mentioned in the Orig Msg below still open then? Thanks a lot to all that helped or tried to! Sorry for missing this on the AxKit FAQ earlier. (I will be posting further if this doesn't close the problem in my AxKit case. It's possible as there are # of bizarre copy bugs in different contexts) V. -Original Message- From: Dave Rolsky [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 14, 2000 4:20 PM To: Khachaturov, Vassilii Cc: '[EMAIL PROTECTED]' Subject: RE: Trouble with AxKit at runtime - XML parsing stage On Thu, 14 Dec 2000, Khachaturov, Vassilii wrote: http://bugs.perl.org/perlbug.cgi?req=querybody=Bizarre+copy seems to yield only one bug relevant to my particular error message case - http://bugs.perl.org/perlbug.cgi?req=bidbid=20001207.005range=6012format= H which is still open. No patch/patchid seen there. Did you mean this bug, or another? Is there some informal patch around? I'm pretty sure that's the bug. Sarathy said it was patched ages ago. I don't know why the bug's still open (you might want to let P5P know about that). -dave /*== www.urth.org We await the New Sun ==*/
RE: Trouble with AxKit at runtime - XML parsing stage
Unfortunately, this is the same obsolete patch I mentioned http://forum.swarthmore.edu/epigone/modperl/spilwhudimp/6B1DF6EEBA51D31182F2 [EMAIL PROTECTED] and it is irrelevant for the perl5.6.0 currently on CPAN :-( -Original Message- From: Jeremy Howard [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 14, 2000 6:43 PM To: Dave Rolsky; Khachaturov, Vassilii Cc: [EMAIL PROTECTED]; Stas Bekman Subject: Re: Trouble with AxKit at runtime - XML parsing stage Dave Rolsky wrote: On Thu, 14 Dec 2000, Khachaturov, Vassilii wrote: http://bugs.perl.org/perlbug.cgi?req=querybody=Bizarre+copy seems to yield only one bug relevant to my particular error message case - http://bugs.perl.org/perlbug.cgi?req=bidbid=20001207.005range=6012format= H which is still open. No patch/patchid seen there. Did you mean this bug, or another? Is there some informal patch around? I'm pretty sure that's the bug. Sarathy said it was patched ages ago. I don't know why the bug's still open (you might want to let P5P know about that). The patch is here: http://www.geocrawler.com/archives/3/182/2000/6/0/3863601/
RE: Order of Installation!!!
How many server processes do you have? Perhaps, you are hitting a different server process every time while testing? Try limiting (for debugging purposes) your server processes # to 1 and see if it makes a difference. Or just test it long enogh to have all the processes load the corresponding perl stuff into them. Vassili http://www.tarunz.org/~vassilii/ -Original Message- From: Edmar Edilton da Silva [mailto:[EMAIL PROTECTED]] Sent: Friday, December 01, 2000 12:41 PM To: [EMAIL PROTECTED] Subject: Order of Installation!!! The problem is that when I run a perl script under mod_perl, the response time is almost the same than the response time of the same script being ran without the mod_perl module. And I know that mod_perl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
installing mod_perl-1.24_01/apache_1.3.14/perl 5.004_04/solaris 5.6
Hi! I have been trying to install the subj combination for a couple of hours with no luck. After looking up Ken's archive, I decided to turn to the list for the help. I have gone exactly through the steps suggested in the apache readme file: $ gunzip apache_1.3.14.tar.gz | tar xvf - $ gunzip mod_perl-1.24_01.tar.gz | tar xvf - $ cd mod_perl-1.24_01 $ perl Makefile.PL APACHE_SRC=../apache_1.3.14/src \ DO_HTTPD=1 USE_APACI=1 \ EVERYTHING=1 (this reports no problems or versioning hints, and successfully completes) $ make This fails at httpd build stage, in the following way: cc -DSOLARIS2=260 -DMOD_PERL -DUSE_PERL_SSI -I/usr/local/include -I/opt/local/include -DNO_DL_NEEDED `./apaci`\ -o httpd buildmark.o modules.o modules/perl/libperl.a modules/standard/libstandard.a main/libmain.a ./os/unix/libos.a ap/libap.a -lsocket -lnsl-L/usr/local/lib -L/opt/local/lib /usr/local/lib/perl5/sun4-solaris/5.00404/auto/DynaLoader/DynaLoader.a -L/usr/local/lib/perl5/sun4-solaris/5.00404/CORE -lperl -lsocket -lnsl -ldl -lm -lc -lcrypt modules/perl/libperl.a(mod_perl.o): In function `perl_shutdown': mod_perl.o(.text+0xc8): undefined reference to `perl_destruct_level' mod_perl.o(.text+0xd4): undefined reference to `perl_destruct_level' mod_perl.o(.text+0xdc): undefined reference to `perl_destruct_level' mod_perl.o(.text+0xe0): undefined reference to `perl_destruct_level' mod_perl.o(.text+0xe4): undefined reference to `perl_destruct_level' modules/perl/libperl.a(mod_perl.o)(.text+0xe8): more undefined references to `perl_destruct_level' follow [suppressed more linker errors screenfuls] Table.o(.text+0x198): undefined reference to `tmps_floor' make[3]: *** [target_static] Error 1 make[3]: Leaving directory `/home/vassilii/src/apache_1.3.14/src' make[2]: *** [build-std] Error 2 make[2]: Leaving directory `/home/vassilii/src/apache_1.3.14' make[1]: *** [build] Error 2 make[1]: Leaving directory `/home/vassilii/src/apache_1.3.14' make: *** [apaci_httpd] Error 2 Any hints will be greatly appreciated! Vassilii
RE: installing mod_perl-1.24_01/apache_1.3.14/perl 5.004_04/solaris 5 .6
Further search in the excellent modperl guide by Stas Bekman at http://perl.apache.org/guide/install.html#Undefined_reference_to_PL_perl_ suggested a clue for this problem: This happens when you have Perl built statically linked, with no shared libperl.a. Build a dynamically linked Perl (with libperl.a) and the problem will disappear. Don't I actually have dynalink support in my perl if perl -V says Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib -L/opt/local/lib' libpth=/usr/local/lib /opt/local/lib /lib /usr/lib /usr/ccs/lib libs=-lsocket -lnsl -ldl -lm -lc -lcrypt libc=/lib/libc.so, so=so useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-Kpic', lddlflags='-G -L/usr/local/lib -L/opt/local/lib' and also the libperl.a is there: /usr/local/lib/perl5/sun4-solaris/5.00404/CORE/libperl.a And, also, to make it 100% sure, I ensured that /usr/local/lib/perl5/sun4-solaris/5.00404/CORE/ is on the httpd's LD_LIBRARY_PATH :-( Vassilii -Original Message- From: Khachaturov, Vassilii Sent: Thursday, October 19, 2000 12:29 PM To: '[EMAIL PROTECTED]' Subject: installing mod_perl-1.24_01/apache_1.3.14/perl 5.004_04/solaris 5 .6 Hi! I have been trying to install the subj combination for a couple of hours with no luck. After looking up Ken's archive, I decided to turn to the list for the help. I have gone exactly through the steps suggested in the apache readme file: ... $ perl Makefile.PL APACHE_SRC=../apache_1.3.14/src \ DO_HTTPD=1 USE_APACI=1 \ EVERYTHING=1 (this reports no problems or versioning hints, and successfully completes) $ make This fails at httpd build stage, in the following way: [see http://forum.swarthmore.edu/epigone/modperl/brelfrermlal ]
