tag:www.nabble.com,2006:forum-183Nabble - mod_perl2008-09-08T01:45:32Zmod_perl is the marriage of Apache and Perl. mod_perl home is <a href="http://perl.apache.org/" target="_top" rel="nofollow">here</a>.tag:www.nabble.com,2006:post-19368128Re: question on downloading CGI2008-09-08T01:45:32Z2008-09-08T01:45:32ZJen mlistsThank you all so much. I have resolved the problems.
<br><br>On Sat, Sep 6, 2008 at 3:51 AM, <<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19368128&i=0" target="_top" rel="nofollow">adam.prime@...</a>> wrote:
<div class='shrinkable-quote'><br>> Quoting <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19368128&i=1" target="_top" rel="nofollow">practicalperl@...</a>:
<br>>
<br>>> Hello,
<br>>>
<br>>> I want to generate a data file which should be downloaded by clients.
<br>>> Rather than generate this file and put it in a web dir and tell
<br>>> clients to download it, is there any way to generate the content
<br>>> dynamicly and put it to cients? I mean I don't want to generate the
<br>>> temporary file. Thanks.
<br>>
<br>> This reads to me like you just want to cause the browser to prompt the user
<br>> to save the file to disk instead of render the content you are generating in
<br>> which case you should read about the Content-Disposition header:
<br>>
<br>> <a href="http://www.ietf.org/rfc/rfc1806.txt" target="_top" rel="nofollow">http://www.ietf.org/rfc/rfc1806.txt</a><br>>
<br>> The quick summary of which is to add a header to your response that looks
<br>> like this:
<br>>
<br>> Content-Disposition: attachment; filename=filename.extention
<br>>
<br>> Adam
<br>>
<br>>
<br>>
<br>>
<br>>
<br>>
<br></div><p>From forum: <a href="http://www.nabble.com/mod_perl---General-f190.html" embed="fixTarget[190]" target="_top" >mod_perl - General</a></p>tag:www.nabble.com,2006:post-19351191Re: Embperl Abandoned: Next Steps?2008-09-06T14:00:41Z2008-09-06T14:00:41ZKaare Rasmussen-3<div class='shrinkable-quote'>> So my question to the community (what's left of it) is this: which
<br>> language/product should I use instead of Embperl/Embperl Object? Here
<br>> are my priorities:
<br>> - Camelness: I would prefer to stay under the Perl umbrella if possible.
<br>> I am not unwilling to learn other languages if necessary but Perl rocks!
<br>> - Power: Properly implemented, Embperl/Embperl Object is VERY powerful
<br>> and productive. I don't want to downgrade to an inferior product
<br>> - Open Source: of course
<br>> - Continuity: I need to choose a product that is not on it's way to
<br>> retirement
<br>> - Documentation: Something well documented (perhaps supported by an
<br>> O'Reilly book).
<br>> - Community: There should be an active community with active discussion
<br>> boards and more than one person enhancing/maintaining the product
<br>> - Linux: Microsoft is out of the question.
</div><br>I think you should look at Catalyst, perhaps the most active Perl Web
<br>development framework. It's a full-featured MVC framework that meets all of
<br>the above requirements.
<br><br>The model part is most often DBIx::Class (if you're talking to databases), and
<br>the view part is mostly recommended to be Template Toolkit. I'm getting tired
<br>og the latter, but in Catalyst you can switch components, so I'm thinking to
<br>use something else.
<br>It's possible to plug in Embperl there, but as you've found, it's not actively
<br>being developed.
<br><br>Perhaps Template::Declare. I like the observation that designers don't
<br>understand templates, only CSS :-)
<br><br>--
<br><br>Med venlig hilsen
<br>Kaare Rasmussen, Jasonic
<br><br>Jasonic Telefon: +45 3816 2582
<br>Nordre Fasanvej 12
<br>2000 Frederiksberg Email: <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19351191&i=0" target="_top" rel="nofollow">kaare@...</a>
<br><br>---------------------------------------------------------------------
<br>To unsubscribe, e-mail: <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19351191&i=1" target="_top" rel="nofollow">embperl-unsubscribe@...</a>
<br>For additional commands, e-mail: <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19351191&i=2" target="_top" rel="nofollow">embperl-help@...</a>
<br><br><p>From forum: <a href="http://www.nabble.com/Embperl-f189.html" embed="fixTarget[189]" target="_top" >Embperl</a></p>tag:www.nabble.com,2006:post-19349580Re: mod_perl 2 and IPC::Open32008-09-06T11:17:39Z2008-09-06T11:17:39ZTina MüllerOn Fri, 5 Sep 2008, Torsten Foertsch wrote:
<br><br>> Don't know if it relates to the problem but this code is quite fragile.
<br>> It depends upon whether $content completely fits into the operating
<br>> systems pipe buffer. In your program the print $wtr or the close $wtr
<br>> statements may infinitely block if $content is too large.
<br><br>thanks for pointing that out, I didn't know that.
<br>To keep it simple, I decided to write the code into a temporary file
<br>and give it as an argument to source-highlight, so that I can call it
<br>with a simple one-directional pipe-open.
<br><br>Still, it would be interesting to know why the code did not work in MP
<br>2.02.
<br><br>regards,
<br>tina
<br><br>--
<br><a href="http://darkdance.net/" target="_top" rel="nofollow">http://darkdance.net/</a><br><a href="http://perlpunks.de/" target="_top" rel="nofollow">http://perlpunks.de/</a><br><a href="http://www.trashcave.de/" target="_top" rel="nofollow">http://www.trashcave.de/</a><br><p>From forum: <a href="http://www.nabble.com/mod_perl---General-f190.html" embed="fixTarget[190]" target="_top" >mod_perl - General</a></p>tag:www.nabble.com,2006:post-19338297Re: question on downloading CGI2008-09-05T12:51:12Z2008-09-05T12:51:12Zadam.primeQuoting <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19338297&i=0" target="_top" rel="nofollow">practicalperl@...</a>:
<br><br>> Hello,
<br>>
<br>> I want to generate a data file which should be downloaded by clients.
<br>> Rather than generate this file and put it in a web dir and tell
<br>> clients to download it, is there any way to generate the content
<br>> dynamicly and put it to cients? I mean I don't want to generate the
<br>> temporary file. Thanks.
<br><br>This reads to me like you just want to cause the browser to prompt the
<br>user to save the file to disk instead of render the content you are
<br>generating in which case you should read about the Content-Disposition
<br>header:
<br><br><a href="http://www.ietf.org/rfc/rfc1806.txt" target="_top" rel="nofollow">http://www.ietf.org/rfc/rfc1806.txt</a><br><br>The quick summary of which is to add a header to your response that
<br>looks like this:
<br><br>Content-Disposition: attachment; filename=filename.extention
<br><br>Adam
<br><br><br><br><br><br><p>From forum: <a href="http://www.nabble.com/mod_perl---General-f190.html" embed="fixTarget[190]" target="_top" >mod_perl - General</a></p>tag:www.nabble.com,2006:post-19335727Re: question on downloading CGI2008-09-05T10:10:25Z2008-09-05T10:10:25ZTorsten FoertschOn Fri 05 Sep 2008, <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19335727&i=0" target="_top" rel="nofollow">practicalperl@...</a> wrote:
<br>> I want to generate a data file which should be downloaded by clients.
<br>> Rather than generate this file and put it in a web dir and tell
<br>> clients to download it, is there any way to generate the content
<br>> dynamicly and put it to cients? I mean I don't want to generate the
<br>> temporary file.
<br><br>Plenty.
<br><br>For example in your httpd.conf
<br><br><Location /download>
<br>SetHandler modperl
<br>PerlResponseHandler "sub { \
<br> use Apache2::RequestRec (); \
<br> use Apache2::RequestIO (); \
<br> use Apache2::Connection (); \
<br> $_[0]->content_type('application/octet-stream'); \
<br> until($_[0]->connection->aborted) { \
<br> $_[0]->print(rand); \
<br> } \
<br> return 0; \
<br>}"
<br></Location>
<br><br>Now restart your server and then
<br><br>curl -v <a href="http://server/download" target="_top" rel="nofollow">http://server/download</a><br><br>And you'll get never ending randomness.
<br><br>You can also write a little shell script and use it via mod_cgi:
<br><br>>>>>>>>>>>>>>>>>>> the shell script
<br>#!/bin/bash
<br>echo Content-Type: application/octet-stream
<br>echo
<br>cat /dev/urandom
<br><<<<<<<<<<<<<<<<<< end of shell script
<br><br>Now fetch the Apache docs and configure your server to execute the
<br>script as CGI program.
<br><br>Remember it is not necessarily faster to send dynamic content this way.
<br>Sometimes it is faster to write a temporary file sometime before the
<br>response phase and let the default handler send it. If you decide to
<br>send the content on the fly try to figure out the content length and
<br>set the Content-Length header. This can also improve your performance.
<br><br>Torsten
<br><br>--
<br>Need professional mod_perl support?
<br>Just hire me: <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19335727&i=1" target="_top" rel="nofollow">torsten.foertsch@...</a>
<br><p>From forum: <a href="http://www.nabble.com/mod_perl---General-f190.html" embed="fixTarget[190]" target="_top" >mod_perl - General</a></p>tag:www.nabble.com,2006:post-19335278Re: question on downloading CGI2008-09-05T09:46:52Z2008-09-05T09:46:52ZSean Davis-3On Fri, Sep 5, 2008 at 12:09 PM, <<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19335278&i=0" target="_top" rel="nofollow">practicalperl@...</a>> wrote:
<br>> Hello,
<br>>
<br>> I want to generate a data file which should be downloaded by clients.
<br>> Rather than generate this file and put it in a web dir and tell
<br>> clients to download it, is there any way to generate the content
<br>> dynamicly and put it to cients? I mean I don't want to generate the
<br>> temporary file. Thanks.
<br><br>Hi, Jen. This list is for mod_perl users. It sounds like you are new
<br>to web programming, but I could be wrong. I would suggest with a
<br>google search for "perl cgi tutorial" and go from there. There is
<br>also a beginners-cgi mailing list (not this) and perlmonks.org is a
<br>great site for general perl knowledge.
<br><br>Sean
<br><p>From forum: <a href="http://www.nabble.com/mod_perl---General-f190.html" embed="fixTarget[190]" target="_top" >mod_perl - General</a></p>tag:www.nabble.com,2006:post-19334529question on downloading CGI2008-09-05T09:09:59Z2008-09-05T09:09:59ZJen mlistsHello,
<br><br>I want to generate a data file which should be downloaded by clients.
<br>Rather than generate this file and put it in a web dir and tell
<br>clients to download it, is there any way to generate the content
<br>dynamicly and put it to cients? I mean I don't want to generate the
<br>temporary file. Thanks.
<br><br><br>Jen.
<br><p>From forum: <a href="http://www.nabble.com/mod_perl---General-f190.html" embed="fixTarget[190]" target="_top" >mod_perl - General</a></p>tag:www.nabble.com,2006:post-19333326Re: Embperl Abandoned: Next Steps?2008-09-05T08:09:39Z2008-09-05T08:09:39ZNeil GuntonWilliams, David G. (HQ-JF000)[INDUS] wrote:
<div class='shrinkable-quote'><br>> It now seems abundantly clear that Embperl development/discussion has
<br>> become very dormant. Perhaps it has been abandoned. I don't wish to
<br>> criticize Gerald for abandoning this project, rather, I would like to
<br>> thank him for his fine work. I have been using Embperl professionally
<br>> since the beginning and am very grateful to him.
<br>>
<br>> Now I am at a crossroads of sorts - I have to choose between continuing
<br>> to develop in Embperl or migrating my code (lots of it) to another
<br>> product that is actively supported. I think it's hard for me to justify
<br>> continuing Embperl development to my client given that the product
<br>> lacks:
<br>> - support
<br>> - ample documentation
<br>> - an active community (a la PHP) (and no, I do not like or advocate PHP)
<br>>
<br>> So my question to the community (what's left of it) is this: which
<br>> language/product should I use instead of Embperl/Embperl Object? Here
<br>> are my priorities:
<br>> - Camelness: I would prefer to stay under the Perl umbrella if possible.
<br>> I am not unwilling to learn other languages if necessary but Perl rocks!
<br>> - Power: Properly implemented, Embperl/Embperl Object is VERY powerful
<br>> and productive. I don't want to downgrade to an inferior product
<br>> - Open Source: of course
<br>> - Continuity: I need to choose a product that is not on it's way to
<br>> retirement
<br>> - Documentation: Something well documented (perhaps supported by an
<br>> O'Reilly book).
<br>> - Community: There should be an active community with active discussion
<br>> boards and more than one person enhancing/maintaining the product
<br>> - Linux: Microsoft is out of the question.
<br>>
<br>> Thank you very much for your time.
<br>>
<br>> David G. Williams
<br>>
</div><br>I wish Gerald would state clearly what his plans and intentions are for
<br>Embperl, so that we users can make plans for either our continued use of
<br>the tool, or transition to some other product, or perhaps even
<br>transferring development to someone else who has time to dedicate to the
<br>open source side of things. I know I have quite a substantial commitment
<br>to Embperl at this point, but no money at the moment. I am still trying
<br>to develop my own sites. If/when I become the internet millionaire then
<br>I would be more than happy to help fund further development and support
<br>for this wonderful tool - I think it still works so well, and would be
<br>very sad to see it disappear through simple neglect. I for one could not
<br>imagine transitioning to PHP from here, that would just be too
<br>depressing. I like the Perl universe.
<br><br>Ruby on Rails seems to be the tool that's been gaining the "buzz" of
<br>late, but I also seem to be getting the impression that the honeymoon
<br>may be over as people start to realize some of the realities of Ruby (no
<br>expert myself there, just what I get the impression of from many posts
<br>skimmed here and there).
<br><br>I'm in the UK visiting family at the moment, but would be glad to
<br>discuss further Embperl development options once I get back home after
<br>Sept 12th. I'm not sure if Gerald has been run over by a bus, or if he
<br>has simply been busy, or just lost interest in the community side of
<br>things here. I remember in the past I got nervous when he appeared to
<br>"go away" for periods of time, but then he always seemed to turn up
<br>again and assure us that everything was ok and was still committed etc.
<br>That's fine, if that's all this is. It would be nice to get an update
<br>from Gerald on his status and intentions, whenever he can get to it.
<br><br>Thanks,
<br><br>Neil
<br><br>---------------------------------------------------------------------
<br>To unsubscribe, e-mail: <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19333326&i=0" target="_top" rel="nofollow">embperl-unsubscribe@...</a>
<br>For additional commands, e-mail: <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19333326&i=1" target="_top" rel="nofollow">embperl-help@...</a>
<br><br><p>From forum: <a href="http://www.nabble.com/Embperl-f189.html" embed="fixTarget[189]" target="_top" >Embperl</a></p>tag:www.nabble.com,2006:post-19331438Embperl Abandoned: Next Steps?2008-09-05T06:37:35Z2008-09-05T06:37:35ZWilliams, David G. (HQ-IF000)[INDUS]It now seems abundantly clear that Embperl development/discussion has
<br>become very dormant. Perhaps it has been abandoned. I don't wish to
<br>criticize Gerald for abandoning this project, rather, I would like to
<br>thank him for his fine work. I have been using Embperl professionally
<br>since the beginning and am very grateful to him.
<br><br>Now I am at a crossroads of sorts - I have to choose between continuing
<br>to develop in Embperl or migrating my code (lots of it) to another
<br>product that is actively supported. I think it's hard for me to justify
<br>continuing Embperl development to my client given that the product
<br>lacks:
<br>- support
<br>- ample documentation
<br>- an active community (a la PHP) (and no, I do not like or advocate PHP)
<br><br>So my question to the community (what's left of it) is this: which
<br>language/product should I use instead of Embperl/Embperl Object? Here
<br>are my priorities:
<br>- Camelness: I would prefer to stay under the Perl umbrella if possible.
<br>I am not unwilling to learn other languages if necessary but Perl rocks!
<br>- Power: Properly implemented, Embperl/Embperl Object is VERY powerful
<br>and productive. I don't want to downgrade to an inferior product
<br>- Open Source: of course
<br>- Continuity: I need to choose a product that is not on it's way to
<br>retirement
<br>- Documentation: Something well documented (perhaps supported by an
<br>O'Reilly book).
<br>- Community: There should be an active community with active discussion
<br>boards and more than one person enhancing/maintaining the product
<br>- Linux: Microsoft is out of the question.
<br><br>Thank you very much for your time.
<br><br>David G. Williams
<br><br><br><br>---------------------------------------------------------------------
<br>To unsubscribe, e-mail: <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19331438&i=0" target="_top" rel="nofollow">embperl-unsubscribe@...</a>
<br>For additional commands, e-mail: <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19331438&i=1" target="_top" rel="nofollow">embperl-help@...</a>
<br><br><p>From forum: <a href="http://www.nabble.com/Embperl-f189.html" embed="fixTarget[189]" target="_top" >Embperl</a></p>tag:www.nabble.com,2006:post-19326225Re: mod_perl 2 and IPC::Open32008-09-05T00:23:57Z2008-09-05T00:23:57ZTorsten FoertschOn Thu 04 Sep 2008, Tina Müller wrote:
<div class='shrinkable-quote'><br>> $pid = open3($wtr, $rdr, $err,
<br>> '/usr/bin/source-highlight', '-s', 'perl', '-css',
<br>> '--no-doc');
<br>> print $wtr $content;
<br>> close $wtr;
<br>> warn __PACKAGE__.':'.__LINE__.": before read loop\n";
<br>> while (<$rdr>) {
<br>> # this is not executed
<br>> warn __PACKAGE__.':'.__LINE__.": line $_\n";
<br>> $highlighted .= $_;
<br>> }
</div><br>Don't know if it relates to the problem but this code is quite fragile.
<br>It depends upon whether $content completely fits into the operating
<br>systems pipe buffer. In your program the print $wtr or the close $wtr
<br>statements may infinitely block if $content is too large.
<br><br>To illustrate that try this:
<br><br>perl -e 'pipe my ($r, $w) or die "pipe: $!\n"; print $w "x"x64000;
<br>warn "printed\n"; close $w;'
<br><br>Here a pipe is created and written to but never read from. This example
<br>succeeds on my linux box. If 64000 is raised to 69000 the "print $w"
<br>succeeds and I see the output of warn(). But the process never ends. It
<br>is blocked in the close() operation. If the buffer length is raised a
<br>bit further to 70000 I don't even see the warning. The process is
<br>blocked in the print() operation. The pipe buffer size depends upon the
<br>operating system. So your numbers may vary.
<br><br>I'd recommend to rewrite that piece based on either perl's select(),
<br>IO::Select or some kind of event library like Lib::Event, EV, Event or
<br>even POE. In all cases you have to use non-blocking IO for reading and
<br>writing combined with sysread/syswrite.
<br><br>Further, I'd suggest a bit of error handling. All those operations
<br>open3, print, close may fail. Only open3 reports the failure via an
<br>exception.
<br><br>Also, you may want to watch out for SIGPIPE.
<br><br>Torsten
<br><br>--
<br>Need professional mod_perl support?
<br>Just hire me: <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19326225&i=0" target="_top" rel="nofollow">torsten.foertsch@...</a>
<br><p>From forum: <a href="http://www.nabble.com/mod_perl---General-f190.html" embed="fixTarget[190]" target="_top" >mod_perl - General</a></p>tag:www.nabble.com,2006:post-19321935RE: mod_perl2 + ModPerl::RegistryPrefork + Test::Builder = segfault2008-09-04T16:15:19Z2008-09-04T16:15:19ZBerg, Eric> On Thu, Sep 4, 2008 at 6:58 PM, Berg, Eric
<br>> > When I say that Test::Builder/Test::More/etc. are tightly
<br>> > coupled, I'm talking really entwined. In some cases, we have
<br>created a
<br>> > class with a bunch of test-related methods that look through the
<br>symbol
<br>> > table and find methods that =~ m/^test_/ and then we run those
<br>tests, which
<br>> > include calls to Test::Builder methods. There's no easy way to turn
<br>> > this off.
<br>>
<br>> This happens even when you're not testing? Or do you really want to
<br>> run those tests every time anyone loads the module?
<br><br>No, we only run those tests when we check them into CVS and the hooks
<br>trigger scripts that run the test methods in our modules. The problem
<br>is that when you load/use Test::Builder, it creates a singleton instance
<br>that does some initialization, including mapping STDERR and STDOUT -- I
<br>believe to class variables. Have you ever noticed how you never see
<br>anything coming out of CPAN mods when you do a make test? I think this
<br>is the reason: stdout and stderr are captured this way.
<br><br>>
<br>> > When you say that we could load it conditionally -- again,
<br>> > not really an option -- are you thinking that we could do a
<br>conditional
<br>> > require() and import explicitly or use fully-qualified calls?
<br>>
<br>> The former - a BEGIN block that determines the situation and loads
<br>> test modules if you're not in mod_perl. You can also do tricks to
<br>> fake Test::Builder's API without loading it, but that's a really
<br>> roundabout way of dealing with the issue.
<br><br>Right. That'd be good if we were't a) subclassing from modules that
<br>directly use Test::Builder methods, and b) have T::B calls throughout
<br>our code.
<br><br>Right now I'm working on figuring out how to disable the mapping (which
<br>appears to happen in Test::Builder->_dup_stdhandles() so that we can
<br>have everything play nicely together.
<br><br>As much as I love having my modules validated whenver they're checked in
<br>(especially for the other developers!) this is killin' me.
<br><br>E
<br>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
<br><br>This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.
<br><br>--------
<br>IRS Circular 230 Disclosure:
<br>Please be advised that any discussion of U.S. tax matters contained within this communication (including any attachments) is not intended or written to be used and cannot be used for the purpose of (i) avoiding U.S. tax related penalties or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein.
<br><p>From forum: <a href="http://www.nabble.com/mod_perl---General-f190.html" embed="fixTarget[190]" target="_top" >mod_perl - General</a></p>tag:www.nabble.com,2006:post-19321812Re: mod_perl2 + ModPerl::RegistryPrefork + Test::Builder = segfault2008-09-04T16:04:39Z2008-09-04T16:04:39ZPerrin HarkinsOn Thu, Sep 4, 2008 at 6:58 PM, Berg, Eric <<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19321812&i=0" target="_top" rel="nofollow">eric.berg@...</a>> wrote:
<br>> When I say that Test::Builder/Test::More/etc. are tightly coupled, I'm
<br>> talking really entwined. In some cases, we have created a class with a
<br>> bunch of test-related methods that look through the symbol table and
<br>> find methods that =~ m/^test_/ and then we run those tests, which
<br>> include calls to Test::Builder methods. There's no easy way to turn
<br>> this off.
<br><br>This happens even when you're not testing? Or do you really want to
<br>run those tests every time anyone loads the module?
<br><br>> When you say that we could load it conditionally -- again, not really an
<br>> option -- are you thinking that we could do a conditional require() and
<br>> import explicitly or use fully-qualified calls?
<br><br>The former - a BEGIN block that determines the situation and loads
<br>test modules if you're not in mod_perl. You can also do tricks to
<br>fake Test::Builder's API without loading it, but that's a really
<br>roundabout way of dealing with the issue.
<br><br>- Perrin
<br><p>From forum: <a href="http://www.nabble.com/mod_perl---General-f190.html" embed="fixTarget[190]" target="_top" >mod_perl - General</a></p>tag:www.nabble.com,2006:post-19321740RE: mod_perl2 + ModPerl::RegistryPrefork + Test::Builder = segfault2008-09-04T15:58:47Z2008-09-04T15:58:47ZBerg, EricHey, Perrin,
<br><br>When I say that Test::Builder/Test::More/etc. are tightly coupled, I'm
<br>talking really entwined. In some cases, we have created a class with a
<br>bunch of test-related methods that look through the symbol table and
<br>find methods that =~ m/^test_/ and then we run those tests, which
<br>include calls to Test::Builder methods. There's no easy way to turn
<br>this off.
<br><br>When you say that we could load it conditionally -- again, not really an
<br>option -- are you thinking that we could do a conditional require() and
<br>import explicitly or use fully-qualified calls?
<br><br>Eric
<br><div class='shrinkable-quote'><br>> -----Original Message-----
<br>> From: <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19321740&i=0" target="_top" rel="nofollow">pharkins@...</a> [mailto:<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19321740&i=1" target="_top" rel="nofollow">pharkins@...</a>] On
<br>> Behalf Of Perrin Harkins
<br>> Sent: Thursday, September 04, 2008 6:36 PM
<br>> To: Berg, Eric
<br>> Cc: <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19321740&i=2" target="_top" rel="nofollow">modperl@...</a>
<br>> Subject: Re: mod_perl2 + ModPerl::RegistryPrefork +
<br>> Test::Builder = segfault
<br>>
<br>> On Thu, Sep 4, 2008 at 6:09 PM, Berg, Eric
<br>> <<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19321740&i=3" target="_top" rel="nofollow">eric.berg@...</a>> wrote:
<br>> > Many of our core modules contain test methods that are
<br>> executed during
<br>> > our CVS checkin process as regression tests, so we'd have
<br>> to completely
<br>> > redo our regression testing architecture to decouple
<br>> Test::Builder from
<br>> > our code.
<br>>
<br>> As a quick fix, you could load it conditionally based on whether or
<br>> not $ENV{MOD_PERL} is true.
<br>>
<br>> - Perrin
<br>>
</div>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
<br><br>This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.
<br><br>--------
<br>IRS Circular 230 Disclosure:
<br>Please be advised that any discussion of U.S. tax matters contained within this communication (including any attachments) is not intended or written to be used and cannot be used for the purpose of (i) avoiding U.S. tax related penalties or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein.
<br><p>From forum: <a href="http://www.nabble.com/mod_perl---General-f190.html" embed="fixTarget[190]" target="_top" >mod_perl - General</a></p>tag:www.nabble.com,2006:post-19321457Re: mod_perl2 + ModPerl::RegistryPrefork + Test::Builder = segfault2008-09-04T15:35:42Z2008-09-04T15:35:42ZPerrin HarkinsOn Thu, Sep 4, 2008 at 6:09 PM, Berg, Eric <<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19321457&i=0" target="_top" rel="nofollow">eric.berg@...</a>> wrote:
<br>> Many of our core modules contain test methods that are executed during
<br>> our CVS checkin process as regression tests, so we'd have to completely
<br>> redo our regression testing architecture to decouple Test::Builder from
<br>> our code.
<br><br>As a quick fix, you could load it conditionally based on whether or
<br>not $ENV{MOD_PERL} is true.
<br><br>- Perrin
<br><p>From forum: <a href="http://www.nabble.com/mod_perl---General-f190.html" embed="fixTarget[190]" target="_top" >mod_perl - General</a></p>tag:www.nabble.com,2006:post-19321056mod_perl2 + ModPerl::RegistryPrefork + Test::Builder = segfault2008-09-04T15:09:21Z2008-09-04T15:09:21ZBerg, EricLooks like we've narrowed the problem that I've described here
<br>(<a href="http://mail-archives.apache.org/mod_mbox/perl-modperl/200808.mbox/%3c5C" target="_top" rel="nofollow">http://mail-archives.apache.org/mod_mbox/perl-modperl/200808.mbox/%3c5C</a><br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19321056&i=0" target="_top" rel="nofollow">AFF755525FC5418CCF35FAEB2683BE12A31A6C@...</a>.
<br>com%3e)
<br><br>It's something having to do with our use of Test::Builder. Simplly
<br>including Test::Builder in a CGI running under ModPerl::RegistryPrefork
<br>causes it to segfault on a very regular basis.
<br><br>Here's the message I posted on CPAN Forum for Test::Simple:
<br><br>>>>>>>>>>>>>>>>
<br>Recently, during the process of porting all my apache 1.3/mod_perl 1.x
<br>CGI's running under ModPerl::RegistryPrefork, I started running into
<br>regular segfaults. After a whole bunch of head scratching and testing,
<br>we narrowed down the problem to our use'ing Test::Builder.
<br><br>It appears to be some kind of conflict that might have to do with the
<br>BEGIN code block that contains these lines for non-threaded Perl:
<br><br> *share = sub { return $_[0] };
<br> *lock = sub { 0 };
<br><br>I don't completely understand what these do in the context of
<br>non-threaded apps, though they appear to be fairly innocuous at first
<br>glance.
<br><br>In any case, it's just using Test::Builder that causes Apache 2.2/mp2 to
<br>segfault.
<br><br>Many of our core modules contain test methods that are executed during
<br>our CVS checkin process as regression tests, so we'd have to completely
<br>redo our regression testing architecture to decouple Test::Builder from
<br>our code.
<br><br>Has anybody had any similar experience with this problem, or can you
<br>help shed some light on the problem to help get us to a solution?
<br><<<<<<<<<<<<<<<
<br><br>Has anybody seen this or anything like it before?
<br><br>Eric
<br>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
<br><br>This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.
<br><br>--------
<br>IRS Circular 230 Disclosure:
<br>Please be advised that any discussion of U.S. tax matters contained within this communication (including any attachments) is not intended or written to be used and cannot be used for the purpose of (i) avoiding U.S. tax related penalties or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein.
<br><p>From forum: <a href="http://www.nabble.com/mod_perl---General-f190.html" embed="fixTarget[190]" target="_top" >mod_perl - General</a></p>tag:www.nabble.com,2006:post-19316134mod_perl 2 and IPC::Open32008-09-04T10:45:08Z2008-09-04T10:45:08ZTina MüllerHi,
<br><br>I'm using source-highlight in a mod_perl application. This program takes
<br>code in STDIN and prints the html-highlighted code to STDOUT.
<br>My code works fine from the commandline and in
<br>Apache/1.3.37 (Unix) mod_perl/1.30
<br>(perl 5.8.8)
<br><br>On another machine it also works from the commandline, but not in
<br>Apache/2.2.3 (Debian) mod_perl/2.0.2 Perl/v5.8.8
<br><br>There is no error, I just cannot get anything from the read handle, it
<br>seems to be empty.
<br>Also an "or die $!" after the open3 is not executed.
<br><br>I searched for similar problems, I found a posting where they said it would
<br>help to untie STDIN before the open3, but this didn't help.
<br><br>I also don't get any lines back from the error handle.
<br><br>Does anybody have an idea what it could be? Maybe I should update to a
<br>more recent mod_perl?
<br><br>The version of IPC::Open3 is 1.02
<br><br>Thanks,
<br>tina
<br><br>Here's the code:
<br># --------------------------
<br>use strict;
<br>use warnings;
<br>use IPC::Open3;
<br>use Data::Dumper;
<br>use POSIX;
<br><br>my $content = <<'EOM';
<br>if ($foo) {
<br> bar() # bar
<br>}
<br>EOM
<br>my $highlighted = '';
<br>my $success = 0;
<br>my $pid;
<br>eval {
<br> my($wtr, $rdr, $err);
<br> $pid = open3($wtr, $rdr, $err,
<br> '/usr/bin/source-highlight', '-s', 'perl', '-css', '--no-doc');
<br> print $wtr $content;
<br> close $wtr;
<br> warn __PACKAGE__.':'.__LINE__.": before read loop\n";
<br> while (<$rdr>) {
<br> # this is not executed
<br> warn __PACKAGE__.':'.__LINE__.": line $_\n";
<br> $highlighted .= $_;
<br> }
<br> # code after the loop is executed
<br>};
<br>if ($@) {
<br> warn __PACKAGE__.':'.__LINE__.": ERROR happened: $@ ($$)\n";
<br> $highlighted = "error";
<br> POSIX::_exit(1);
<br> die "oops ($$)";
<br>}
<br>else {
<br> my $exit = waitpid $pid, 0;
<br> $success = 1 if $exit;
<br>}
<br># --------------------------
<br><br><br>--
<br><a href="http://darkdance.net/" target="_top" rel="nofollow">http://darkdance.net/</a><br><a href="http://perlpunks.de/" target="_top" rel="nofollow">http://perlpunks.de/</a><br><a href="http://www.trashcave.de/" target="_top" rel="nofollow">http://www.trashcave.de/</a><br><p>From forum: <a href="http://www.nabble.com/mod_perl---General-f190.html" embed="fixTarget[190]" target="_top" >mod_perl - General</a></p>tag:www.nabble.com,2006:post-19314169Stacktrace of segfault on fork in mp2/perl-5.102008-09-04T09:12:57Z2008-09-04T09:12:57ZBerg, EricI posted this a little while ago, and was hoping that some of you
<br>C-oriented folks could take a look at this stack trace and see if
<br>anything jumps out at you that would indicate why I'm consistently
<br>getting segmentation faults (11) when forking in a CGI running under
<br>ModPerl::RegistryPrefork.
<br><br>Thanks for any insight you can provide.
<br><br>[Wed Aug 27 18:29:29 2008] pid 24456 mod_backtrace backtrace for sig 11
<br>(thread "pid" 24456)
<br>[Wed Aug 27 18:29:29 2008] pid 24456 mod_backtrace main() is at 8062fb8
<br>/home/pointsrv/apache/config/dev/modules/mod_backtrace.so[0xa3fa43]
<br>/home/erberg/public_html/work/point-www/aut(ap_run_fatal_exception+0x2e)
<br>[0x8079ce2]
<br>/home/erberg/public_html/work/point-www/aut[0x807b0a0]
<br>/lib/tls/libpthread.so.0[0x5b9a98]
<br>/home/pointsrv/apache/config/dev/modules/mod_perl.so(Perl_PerlIO_flush+0
<br>x68)[0x116e648]
<br>/home/pointsrv/apache/config/dev/modules/mod_perl.so(Perl_pp_fork+0x45)[
<br>0x1149b55]
<br>/home/pointsrv/apache/config/dev/modules/mod_perl.so(Perl_runops_standar
<br>d+0x18)[0x1102fe8]
<br>/home/pointsrv/apache/config/dev/modules/mod_perl.so(Perl_call_sv+0x49a)
<br>[0x110106a]
<br>/home/pointsrv/apache/config/dev/modules/mod_perl.so(modperl_callback+0x
<br>180)[0x10764f0]
<br>/home/pointsrv/apache/config/dev/modules/mod_perl.so(modperl_callback_ru
<br>n_handlers+0x35a)[0x1076b3a]
<br>/home/pointsrv/apache/config/dev/modules/mod_perl.so(modperl_callback_pe
<br>r_dir+0x53)[0x1076e83]
<br>/home/pointsrv/apache/config/dev/modules/mod_perl.so(modperl_response_ha
<br>ndler_cgi+0x11b)[0x107354b]
<br>/home/erberg/public_html/work/point-www/aut(ap_run_handler+0x32)[0x80735
<br>6e]
<br>/home/erberg/public_html/work/point-www/aut(ap_invoke_handler+0xad)[0x80
<br>73939]
<br>/home/erberg/public_html/work/point-www/aut(ap_process_request+0x18d)[0x
<br>807e669]
<br>/home/erberg/public_html/work/point-www/aut[0x807c145]
<br>/home/erberg/public_html/work/point-www/aut(ap_run_process_connection+0x
<br>32)[0x8078e12]
<br>/home/erberg/public_html/work/point-www/aut[0x80822c9]
<br>/home/erberg/public_html/work/point-www/aut[0x808249e]
<br>/home/erberg/public_html/work/point-www/aut[0x808252c]
<br>[Wed Aug 27 18:29:29 2008] pid 24456 mod_backtrace end of backtrace
<br>[Wed Aug 27 18:29:30 2008] [notice] child pid 24456 exit
<br>signal Segmentation fault (11), possible coredump in /tmp
<br><br><br>Eric Berg
<br><br><br>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
<br><br>This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.
<br><br>--------
<br>IRS Circular 230 Disclosure:
<br>Please be advised that any discussion of U.S. tax matters contained within this communication (including any attachments) is not intended or written to be used and cannot be used for the purpose of (i) avoiding U.S. tax related penalties or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein.
<br><p>From forum: <a href="http://www.nabble.com/mod_perl---General-f190.html" embed="fixTarget[190]" target="_top" >mod_perl - General</a></p>tag:www.nabble.com,2006:post-19308757Output of external program is getting lost in mod_perl 2.0.42008-09-04T04:50:43Z2008-09-04T04:50:43ZShibi NS<div dir="ltr"><div>Hi,</div><div><br></div><div>I am migrating my application from httpd 1.x and mod_perl 1.x to mod_perl-2.0.4 and httpd-2.2.9. Some of the forms in my application uses and standalone script which excutes some external scripts</div>
<div>like os commands or some other perl/shell scripts. </div><div><br></div><div>Here is the source code for the script that executes an external program <a href="http://rafb.net/p/Wjj41u36.html" target="_top" rel="nofollow">http://rafb.net/p/Wjj41u36.html</a> </div>
<div><br></div><div><br></div><div>Here the function do_cmd executes and stores output to self->{DOCMD_OUTPUT} . This was working fine when we executing mod_perl 1.x but after we migrated to</div><div>mod_perl 2.0.4 as we call get_last_do_cmd_output function the output is empty. Any idea where the output is lost ? . Look at do_cmd and _for_exec function to see how </div>
<div>we are re-directing the output to a pipe</div><div><br></div><div><br></div><div><br></div><div><br></div>--Shibi Ns--<br>
</div>
<p>From forum: <a href="http://www.nabble.com/mod_perl---General-f190.html" embed="fixTarget[190]" target="_top" >mod_perl - General</a></p>tag:www.nabble.com,2006:post-19293397Re: mod_perl users survey2008-09-03T09:55:17Z2008-09-03T09:55:17Zadam.prime<br>One final call for responses. It'd also be appreciated if you could
<br>forward the survey on to your local Perl Mongers Groups to help us
<br>reach some people that might be a little more disconnected from the
<br>mod_perl community.
<br><br>We've got over 300 responses so far, thanks to everyone that has taken
<br>the time to respond.
<br><br>Adam
<br><br><div class='shrinkable-quote'><br>> Quoting <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19293397&i=0" target="_top" rel="nofollow">adam.prime@...</a>:
<br>>
<br>>> At the impromptu mod_perl BOF at YAPC::NA, Fred Moyer any myself
<br>>> hacked together a short mod_perl survey to help identify the current
<br>>> needs of mod_perl users. It was inspired by the Perl survey done last
<br>>> year by Kirrily Robert. (<a href="http://perlsurvey.org" target="_top" rel="nofollow">http://perlsurvey.org</a>). If you read dev@ and
<br>>> already filled this out, please don't do it again.
<br>>>
<br>>> The link is here:
<br>>>
<br>>> <a href="http://www.surveymonkey.com/s.aspx?sm=bQyb2RFCBuVb0P52yhaCMg_3d_3d" target="_top" rel="nofollow">http://www.surveymonkey.com/s.aspx?sm=bQyb2RFCBuVb0P52yhaCMg_3d_3d</a><br>>>
<br>>> The survey seeks to attain these goals:
<br>>>
<br>>> 1) Determine the current breakdown of mod_perl users in terms of what
<br>>> versions, modules, and platforms mod_perl users are using.
<br>>>
<br>>> 2) Give mod_perl users a chance to provide feedback to the development
<br>>> team on where they think mod_perl development should be headed.
<br>>>
<br>>> Please take a few minutes and fill it out. Neither of us are
<br>>> statisticians, and there are plenty of questions that haven't been
<br>>> asked, but we only get 10 questions for free with survey monkey, so
<br>>> we've done what we could with our non-existant resources.
<br>>>
<br>>> Thanks,
<br>>> Adam
<br>>>
<br>>>
<br>>>
<br>>
<br>>
<br>>
<br>>
</div><br><br><br><p>From forum: <a href="http://www.nabble.com/mod_perl---General-f190.html" embed="fixTarget[190]" target="_top" >mod_perl - General</a></p>tag:www.nabble.com,2006:post-19276866Re: mp2, STDIN/POST is clobbered by CGI->new($r);2008-09-02T12:34:57Z2008-09-02T12:34:57ZPerrin HarkinsOn Fri, Aug 29, 2008 at 6:35 PM, Ashley Pond V <<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19276866&i=0" target="_top" rel="nofollow">ashley.pond.v@...</a>> wrote:
<br>> How could you read the POST body without clobbering it to hand off to some
<br>> PHP, or whatever is next in line?
<br><br>I don't think you can. Usually people use something like libapreq to
<br>get around this, since it can just keep the parsed data and let you
<br>use it across multiple phases, but that only works when everyone is
<br>calling libapreq for their data.
<br><br>- Perrin
<br><p>From forum: <a href="http://www.nabble.com/mod_perl---General-f190.html" embed="fixTarget[190]" target="_top" >mod_perl - General</a></p>tag:www.nabble.com,2006:post-19265513Re: mod_perl compilation problem2008-09-02T00:37:07Z2008-09-02T00:37:07ZEbner.EJ.Johannes<div class='shrinkable-quote'><br>>Dan Axtell wrote:
<br>>> I'm still trying to figure out how to build mod_perl on an
<br>>AMD x86_64 system.
<br>>> It's running gcc 4.1.1 on Red Hat 4.1.1-52. Perl 5.8.8 +
<br>>Apache + mod_perl is
<br>>> already installed, but I wanted to try and build everything
<br>>with 5.10 because
<br>>> I've read that the RedHat Perl binaries are sometimes very
<br>>slow, and I want to
<br>>> check out some of the Perl 5.10 features on a new server.
<br>>>
<br>>> I'm building Perl with these options:
<br>>> Configure -de -Dprefix=/usr/local -Accflags="-fPIC"
<br>>>
<br>>> Perl builds, tests, and seems to run fine.
<br>>>
<br>>> When I make mod_perl, I get this error:
<br>>>
<br>>> /usr/bin/ld:
<br>>/usr/local/lib/perl5/5.10.0/x86_64-linux/CORE/libperl.a(gv.o):
<br>>> relocation R_X86_64_32 against `a local symbol' can not be
<br>>used when making a
<br>>> shared object; recompile with -fPIC
<br>>> /usr/local/lib/perl5/5.10.0/x86_64-linux/CORE/libperl.a:
<br>>could not read
<br>>> symbols: Bad value
<br>>> collect2: ld returned 1 exit status
<br>>>
<br>>> If I'm building Perl explicity with -fPIC, why does mod_perl
<br>>think I'm not?
<br>>
<br>>Did you remove all previous perl build fragments that may have been
<br>>compiled without -fPIC? That is, can you try a clean install with a
<br>>prefix like /home/myuser/testperl, and then try to build mod_perl
<br>>against that perl installation?
<br>>
<br>>I haven't tried 5.10 on x86_64 yet.
<br>>
<br>>>
<br>>> I suppose I can live with 5.8.8, but there should be a way
<br>>to build this.
<br>>>
<br>>> Dan
<br>>
<br>>
</div><br><br>I tried mod_perl on SLES 10 AMD64 worked perfectly with Perl 5.10 - but
<br>with the compile options for Perl you specified earlier (-fPIC). What
<br>Fred is writing looks like the best solution to me.
<br><p>From forum: <a href="http://www.nabble.com/mod_perl---General-f190.html" embed="fixTarget[190]" target="_top" >mod_perl - General</a></p>tag:www.nabble.com,2006:post-19254827Re: mod_perl compilation problem2008-09-01T06:30:20Z2008-09-01T06:30:20ZDan Axtell> Did you remove all previous perl build fragments that may have been
<br>> compiled without -fPIC? That is, can you try a clean install with a
<br>> prefix like /home/myuser/testperl, and then try to build mod_perl
<br>> against that perl installation?
<br>>
<br>I'll try that next.
<br><br>Question: my home box is opensuse 11.0 and it comes with perl 5.10 + mod_perl
<br>for and AMD x86_64. Can I just upload the mod_perl.so binary, or will small
<br>differences like the perl binary being in different locations stop it from
<br>working?
<br><p>From forum: <a href="http://www.nabble.com/mod_perl---General-f190.html" embed="fixTarget[190]" target="_top" >mod_perl - General</a></p>tag:www.nabble.com,2006:post-19248464Re: mod_perl compilation problem2008-08-31T20:28:29Z2008-08-31T20:28:29ZFred MoyerDan Axtell wrote:
<div class='shrinkable-quote'><br>> I'm still trying to figure out how to build mod_perl on an AMD x86_64 system.
<br>> It's running gcc 4.1.1 on Red Hat 4.1.1-52. Perl 5.8.8 + Apache + mod_perl is
<br>> already installed, but I wanted to try and build everything with 5.10 because
<br>> I've read that the RedHat Perl binaries are sometimes very slow, and I want to
<br>> check out some of the Perl 5.10 features on a new server.
<br>>
<br>> I'm building Perl with these options:
<br>> Configure -de -Dprefix=/usr/local -Accflags="-fPIC"
<br>>
<br>> Perl builds, tests, and seems to run fine.
<br>>
<br>> When I make mod_perl, I get this error:
<br>>
<br>> /usr/bin/ld: /usr/local/lib/perl5/5.10.0/x86_64-linux/CORE/libperl.a(gv.o):
<br>> relocation R_X86_64_32 against `a local symbol' can not be used when making a
<br>> shared object; recompile with -fPIC
<br>> /usr/local/lib/perl5/5.10.0/x86_64-linux/CORE/libperl.a: could not read
<br>> symbols: Bad value
<br>> collect2: ld returned 1 exit status
<br>>
<br>> If I'm building Perl explicity with -fPIC, why does mod_perl think I'm not?
</div><br>Did you remove all previous perl build fragments that may have been
<br>compiled without -fPIC? That is, can you try a clean install with a
<br>prefix like /home/myuser/testperl, and then try to build mod_perl
<br>against that perl installation?
<br><br>I haven't tried 5.10 on x86_64 yet.
<br><br>>
<br>> I suppose I can live with 5.8.8, but there should be a way to build this.
<br>>
<br>> Dan
<br><p>From forum: <a href="http://www.nabble.com/mod_perl---General-f190.html" embed="fixTarget[190]" target="_top" >mod_perl - General</a></p>tag:www.nabble.com,2006:post-19248291mod_perl compilation problem2008-08-31T19:55:35Z2008-08-31T19:55:35ZDan AxtellI'm still trying to figure out how to build mod_perl on an AMD x86_64 system.
<br>It's running gcc 4.1.1 on Red Hat 4.1.1-52. Perl 5.8.8 + Apache + mod_perl is
<br>already installed, but I wanted to try and build everything with 5.10 because
<br>I've read that the RedHat Perl binaries are sometimes very slow, and I want to
<br>check out some of the Perl 5.10 features on a new server.
<br><br>I'm building Perl with these options:
<br>Configure -de -Dprefix=/usr/local -Accflags="-fPIC"
<br><br>Perl builds, tests, and seems to run fine.
<br><br>When I make mod_perl, I get this error:
<br><br>/usr/bin/ld: /usr/local/lib/perl5/5.10.0/x86_64-linux/CORE/libperl.a(gv.o):
<br>relocation R_X86_64_32 against `a local symbol' can not be used when making a
<br>shared object; recompile with -fPIC
<br>/usr/local/lib/perl5/5.10.0/x86_64-linux/CORE/libperl.a: could not read
<br>symbols: Bad value
<br>collect2: ld returned 1 exit status
<br><br>If I'm building Perl explicity with -fPIC, why does mod_perl think I'm not?
<br><br>I suppose I can live with 5.8.8, but there should be a way to build this.
<br><br>Dan
<br><p>From forum: <a href="http://www.nabble.com/mod_perl---General-f190.html" embed="fixTarget[190]" target="_top" >mod_perl - General</a></p>tag:www.nabble.com,2006:post-19228485mp2, STDIN/POST is clobbered by CGI->new($r);2008-08-29T15:35:13Z2008-08-29T15:35:13ZAshley-23Hello everybody.
<br><br>I've got an access handler that is checking some arguments before
<br>passing the request off with DECLINED or redirecting back to login/home.
<br><br>The first version broke PHP forms that used POST by using this idiom
<br>to check for arguments:
<br><br> my $cgi = CGI->new($r);
<br><br>CGI, I am guessing, reads STDIN for the POST args, emptying it
<br>(eof'ing it?). So, when an authenticated request is DECLINED and PHP
<br>is next in line, there is nothing to read and the $_POST is empty.
<br><br>I realized I only needed to check GET args for the session info so
<br>munging $r->args is fine for my situation. Problem solved but now I'm
<br>curious.
<br><br>How could you read the POST body without clobbering it to hand off to
<br>some PHP, or whatever is next in line? My CGI version in this
<br>environment is 3.15.
<br><br>Thanks!
<br>-Ashley
<br><br><p>From forum: <a href="http://www.nabble.com/mod_perl---General-f190.html" embed="fixTarget[190]" target="_top" >mod_perl - General</a></p>tag:www.nabble.com,2006:post-19227994Re: Virtual Directories2008-08-29T14:51:13Z2008-08-29T14:51:13ZPerrin HarkinsOn Fri, Aug 29, 2008 at 4:26 PM, Will Fould <<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19227994&i=0" target="_top" rel="nofollow">willfould@...</a>> wrote:
<br>> Assuming my code can look in an existing database/memcache with the
<br>> requested URI segment, can someone suggest the lightest/fastest ways to
<br>> accomplish this or provide a decent link to a better discussion?
<br><br>Some options:
<br>- mod_rewrite
<br>- PerlTransHandler
<br>- PerlResponseHandler that sends the actual file
<br><br>If you can use mod_rewrite, that's the lightest option.
<br><br>- Perrin
<br><p>From forum: <a href="http://www.nabble.com/mod_perl---General-f190.html" embed="fixTarget[190]" target="_top" >mod_perl - General</a></p>tag:www.nabble.com,2006:post-19227326RE: a require problem2008-08-29T13:55:26Z2008-08-29T13:55:26ZBerg, EricI'm running this:
<br><br> Apache/2.2.9 (Unix) mod_apreq2-20051231/2.6.0 mod_perl/2.0.4
<br>Perl/v5.10.0
<br><br>This is not my biggest problem right now. As you know, I'm still
<br>wrestling with problems associated with Parallel::ForkManager.
<br><br>I'm going to put together a discrete test of this problem for
<br>demonstration purposes and get back to trying some different versions of
<br>apache, Perl and mod_perl to see if this bug was introduced at some
<br>point along the development path.
<br><br>Eric
<br><div class='shrinkable-quote'><br>> -----Original Message-----
<br>> From: <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19227326&i=0" target="_top" rel="nofollow">pharkins@...</a> [mailto:<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19227326&i=1" target="_top" rel="nofollow">pharkins@...</a>] On
<br>> Behalf Of Perrin Harkins
<br>> Sent: Friday, August 29, 2008 4:16 PM
<br>> To: Berg, Eric
<br>> Cc: <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19227326&i=2" target="_top" rel="nofollow">niels@...</a>; modperl perl apache org
<br>> Subject: Re: a require problem
<br>>
<br>> On Fri, Aug 29, 2008 at 3:43 PM, Berg, Eric
<br>> <<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19227326&i=3" target="_top" rel="nofollow">eric.berg@...</a>> wrote:
<br>> > For me, it's the same on both.
<br>>
<br>> Nevertheless, there have been problems in the past with GID. Are you
<br>> running the latest mod_perl, and perl 5.8.8 or later? See this for
<br>> background:
<br>> <a href="http://marc.info/?l=apache-modperl&m=117922708110568&w=2" target="_top" rel="nofollow">http://marc.info/?l=apache-modperl&m=117922708110568&w=2</a><br>>
<br>> - Perrin
<br>>
</div>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
<br><br>This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.
<br><br>--------
<br>IRS Circular 230 Disclosure:
<br>Please be advised that any discussion of U.S. tax matters contained within this communication (including any attachments) is not intended or written to be used and cannot be used for the purpose of (i) avoiding U.S. tax related penalties or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein.
<br><p>From forum: <a href="http://www.nabble.com/mod_perl---General-f190.html" embed="fixTarget[190]" target="_top" >mod_perl - General</a></p>tag:www.nabble.com,2006:post-19226933Virtual Directories2008-08-29T13:26:39Z2008-08-29T13:26:39ZWill Fould<div dir="ltr">Hello - <br><br>This has got to be very common:<br><br>I've got a list of directories:<br><br> <a href="http://www.example.com/foo" target="_top" rel="nofollow">http://www.example.com/foo</a><br>
<a href="http://www.example.com/bar" target="_top" rel="nofollow">http://www.example.com/bar</a><br>
<a href="http://www.example.com/..." target="_top" rel="nofollow">http://www.example.com/...</a>..<br><br>These directories don't exist in the web root but map to the real location on the file system:<br><br> /var/customers/12345<br>
/var/customers/12346<br>
/var/customers/.....<br><br>... (location determined by a database/memcached lookup).<br><br>Assuming my code can look in an existing database/memcache with the requested URI segment, can someone suggest the lightest/fastest ways to accomplish this or provide a decent link to a better discussion?<br>
<br><br>Thanks in advance!!<br></div>
<p>From forum: <a href="http://www.nabble.com/mod_perl---General-f190.html" embed="fixTarget[190]" target="_top" >mod_perl - General</a></p>tag:www.nabble.com,2006:post-19226740Re: a require problem2008-08-29T13:16:24Z2008-08-29T13:16:24ZPerrin HarkinsOn Fri, Aug 29, 2008 at 3:43 PM, Berg, Eric <<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19226740&i=0" target="_top" rel="nofollow">eric.berg@...</a>> wrote:
<br>> For me, it's the same on both.
<br><br>Nevertheless, there have been problems in the past with GID. Are you
<br>running the latest mod_perl, and perl 5.8.8 or later? See this for
<br>background:
<br><a href="http://marc.info/?l=apache-modperl&m=117922708110568&w=2" target="_top" rel="nofollow">http://marc.info/?l=apache-modperl&m=117922708110568&w=2</a><br><br>- Perrin
<br><p>From forum: <a href="http://www.nabble.com/mod_perl---General-f190.html" embed="fixTarget[190]" target="_top" >mod_perl - General</a></p>tag:www.nabble.com,2006:post-19226782RE: a require problem2008-08-29T13:15:40Z2008-08-29T13:15:40ZNiels Larsen-3What does 'file $cmd' (the gnu file program) say? is -e true
<br>under mod_perl? I'm out of ideas, but if you are certain its not
<br>due to different Apache configuration, then maybe sifting though
<br>strace output would be worth trying .. and i'm new to mod_perl
<br>anyway. Good luck. My errors are often obvious and found right
<br>in the places where I am not looking.
<br><br>Niels L
<br><br>> For me, it's the same on both.
<br>>
<br>> What could be the problem here? How can we take the next steps in
<br>> debugging this?
<br>>
<br>> ERic
<br><br><br><p>From forum: <a href="http://www.nabble.com/mod_perl---General-f190.html" embed="fixTarget[190]" target="_top" >mod_perl - General</a></p>tag:www.nabble.com,2006:post-19226291RE: a require problem2008-08-29T12:43:28Z2008-08-29T12:43:28ZBerg, EricFor me, it's the same on both.
<br><br>What could be the problem here? How can we take the next steps in
<br>debugging this?
<br><br>ERic
<br><div class='shrinkable-quote'><br>> -----Original Message-----
<br>> From: <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19226291&i=0" target="_top" rel="nofollow">niels@...</a> [mailto:<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19226291&i=1" target="_top" rel="nofollow">niels@...</a>]
<br>> Sent: Friday, August 29, 2008 3:01 PM
<br>> To: Berg, Eric
<br>> Cc: modperl perl apache org
<br>> Subject: RE: a require problem
<br>>
<br>> Could it be that during forking a different effective user id is
<br>> set, which is what -x checks? are $<, $>, $( and $) all the same
<br>> under cgi and mod_perl?
<br>>
<br>> (it sounds like /usr/bin/rcsdiff is not a symbolic link, which
<br>> could be treated differently maybe, followsymlinks, etc)
<br>>
<br>> Niels L
<br>>
<br>> > The mod_perl server and the CGI server are the same. It's just a
<br>> > handler configured for CGI's for *.cgi and mod_perl for
<br>> *.pl, and I've
<br>> > symlinked from a .pl to the .cgi.
<br>> >
<br>> > The web server for CGI and mod_perl and the command line
<br>> run were all
<br>> > done as the same user.
<br>> >
<br>> > Code like this:
<br>> >
<br>> > warn "$cmd is " . (-x $cmd ? "" : " not") ." EXECUTABLE\n" ;
<br>> > warn `ls -l $cmd`;
<br>> >
<br>> > Yields this under mod_perl:
<br>> >
<br>> > /usr/bin/rcsdiff is not EXECUTABLE
<br>> > -rwxr-xr-x 1 root root 49388 Sep 21 2004 /usr/bin/rcsdiff
<br>> >
<br>> > and this from the command line and
<br>> >
<br>> > /usr/bin/rcsdiff is EXECUTABLE
<br>> > -rwxr-xr-x 1 root root 49388 Sep 21 2004 /usr/bin/rcsdiff
<br>> >
<br>> > and in a CGI:
<br>> >
<br>> > /usr/bin/rcsdiff is EXECUTABLE
<br>> > -rwxr-xr-x 1 root root 49388 Sep 21 2004 /usr/bin/rcsdiff
<br>> >
<br>> > Same server, CGI vs mod_perl, different behavior.
<br>> >
<br>> > Probably not permissions. But what?
<br>> >
<br>> > Eric
<br>>
<br>>
<br>>
</div>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
<br><br>This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.
<br><br>--------
<br>IRS Circular 230 Disclosure:
<br>Please be advised that any discussion of U.S. tax matters contained within this communication (including any attachments) is not intended or written to be used and cannot be used for the purpose of (i) avoiding U.S. tax related penalties or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein.
<br><p>From forum: <a href="http://www.nabble.com/mod_perl---General-f190.html" embed="fixTarget[190]" target="_top" >mod_perl - General</a></p>tag:www.nabble.com,2006:post-19225683RE: a require problem2008-08-29T12:01:05Z2008-08-29T12:01:05ZNiels Larsen-3Could it be that during forking a different effective user id is
<br>set, which is what -x checks? are $<, $>, $( and $) all the same
<br>under cgi and mod_perl?
<br><br>(it sounds like /usr/bin/rcsdiff is not a symbolic link, which
<br>could be treated differently maybe, followsymlinks, etc)
<br><br>Niels L
<br><div class='shrinkable-quote'><br>> The mod_perl server and the CGI server are the same. It's just a
<br>> handler configured for CGI's for *.cgi and mod_perl for *.pl, and I've
<br>> symlinked from a .pl to the .cgi.
<br>>
<br>> The web server for CGI and mod_perl and the command line run were all
<br>> done as the same user.
<br>>
<br>> Code like this:
<br>>
<br>> warn "$cmd is " . (-x $cmd ? "" : " not") ." EXECUTABLE\n" ;
<br>> warn `ls -l $cmd`;
<br>>
<br>> Yields this under mod_perl:
<br>>
<br>> /usr/bin/rcsdiff is not EXECUTABLE
<br>> -rwxr-xr-x 1 root root 49388 Sep 21 2004 /usr/bin/rcsdiff
<br>>
<br>> and this from the command line and
<br>>
<br>> /usr/bin/rcsdiff is EXECUTABLE
<br>> -rwxr-xr-x 1 root root 49388 Sep 21 2004 /usr/bin/rcsdiff
<br>>
<br>> and in a CGI:
<br>>
<br>> /usr/bin/rcsdiff is EXECUTABLE
<br>> -rwxr-xr-x 1 root root 49388 Sep 21 2004 /usr/bin/rcsdiff
<br>>
<br>> Same server, CGI vs mod_perl, different behavior.
<br>>
<br>> Probably not permissions. But what?
<br>>
<br>> Eric
</div><br><br><p>From forum: <a href="http://www.nabble.com/mod_perl---General-f190.html" embed="fixTarget[190]" target="_top" >mod_perl - General</a></p>tag:www.nabble.com,2006:post-19225655Re: a require problem2008-08-29T11:59:08Z2008-08-29T11:59:08ZPerrin HarkinsOn Fri, Aug 29, 2008 at 2:04 PM, Berg, Eric <<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19225655&i=0" target="_top" rel="nofollow">eric.berg@...</a>> wrote:
<br>> The mod_perl server and the CGI server are the same.
<br><br>Even so, CGI is often configured to execute the script as the owner of
<br>the file, rather than as the user running the web server, so make sure
<br>you really are the same user.
<br><br>> Probably not permissions. But what?
<br><br>Well, ultimately, it is permissions. I remember some discussions a
<br>while back on the list about gid possibly not being set correctly by
<br>mod_perl. You might look that up in the archives. You might also try
<br>checking your real and effective uid and gid under CGI and mod_perl.
<br><br>- Perrin
<br><p>From forum: <a href="http://www.nabble.com/mod_perl---General-f190.html" embed="fixTarget[190]" target="_top" >mod_perl - General</a></p>tag:www.nabble.com,2006:post-19224831RE: a require problem2008-08-29T11:04:44Z2008-08-29T11:04:44ZBerg, EricThe mod_perl server and the CGI server are the same. It's just a
<br>handler configured for CGI's for *.cgi and mod_perl for *.pl, and I've
<br>symlinked from a .pl to the .cgi.
<br><br>The web server for CGI and mod_perl and the command line run were all
<br>done as the same user.
<br><br>Code like this:
<br><br> warn "$cmd is " . (-x $cmd ? "" : " not") ." EXECUTABLE\n" ;
<br> warn `ls -l $cmd`;
<br><br>Yields this under mod_perl:
<br><br>/usr/bin/rcsdiff is not EXECUTABLE
<br>-rwxr-xr-x 1 root root 49388 Sep 21 2004 /usr/bin/rcsdiff
<br><br>and this from the command line and
<br><br>/usr/bin/rcsdiff is EXECUTABLE
<br>-rwxr-xr-x 1 root root 49388 Sep 21 2004 /usr/bin/rcsdiff
<br><br>and in a CGI:
<br><br>/usr/bin/rcsdiff is EXECUTABLE
<br>-rwxr-xr-x 1 root root 49388 Sep 21 2004 /usr/bin/rcsdiff
<br><br>Same server, CGI vs mod_perl, different behavior.
<br><br>Probably not permissions. But what?
<br><br>Eric
<br><div class='shrinkable-quote'><br>> -----Original Message-----
<br>> From: <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19224831&i=0" target="_top" rel="nofollow">pharkins@...</a> [mailto:<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19224831&i=1" target="_top" rel="nofollow">pharkins@...</a>] On
<br>> Behalf Of Perrin Harkins
<br>> Sent: Friday, August 29, 2008 1:35 PM
<br>> To: Berg, Eric
<br>> Cc: Sean Davis; Jeff Pang; modperl perl apache org
<br>> Subject: Re: a require problem
<br>>
<br>> On Fri, Aug 29, 2008 at 1:23 PM, Berg, Eric
<br>> <<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19224831&i=2" target="_top" rel="nofollow">eric.berg@...</a>> wrote:
<br>> > The really weird thing is that when run in a CGI context,
<br>> the -x test
<br>> > works as expected, but when called when running as a
<br>> mod_perl2 registry
<br>> > script, it returns false, even though the file (that does exist) is
<br>> > executable by everyone. Change it back to CGI (not
<br>> mod_perl) and the
<br>> > same code does work properly.
<br>>
<br>> It's still most likely a permissions issue. I'd suggest trying to
<br>> execute it as the user who your mod_perl server runs as.
<br>>
<br>> - Perrin
<br>>
</div>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
<br><br>This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.
<br><br>--------
<br>IRS Circular 230 Disclosure:
<br>Please be advised that any discussion of U.S. tax matters contained within this communication (including any attachments) is not intended or written to be used and cannot be used for the purpose of (i) avoiding U.S. tax related penalties or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein.
<br><p>From forum: <a href="http://www.nabble.com/mod_perl---General-f190.html" embed="fixTarget[190]" target="_top" >mod_perl - General</a></p>tag:www.nabble.com,2006:post-19224397Re: a require problem2008-08-29T10:35:25Z2008-08-29T10:35:25ZPerrin HarkinsOn Fri, Aug 29, 2008 at 1:23 PM, Berg, Eric <<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19224397&i=0" target="_top" rel="nofollow">eric.berg@...</a>> wrote:
<br>> The really weird thing is that when run in a CGI context, the -x test
<br>> works as expected, but when called when running as a mod_perl2 registry
<br>> script, it returns false, even though the file (that does exist) is
<br>> executable by everyone. Change it back to CGI (not mod_perl) and the
<br>> same code does work properly.
<br><br>It's still most likely a permissions issue. I'd suggest trying to
<br>execute it as the user who your mod_perl server runs as.
<br><br>- Perrin
<br><p>From forum: <a href="http://www.nabble.com/mod_perl---General-f190.html" embed="fixTarget[190]" target="_top" >mod_perl - General</a></p>