[ANNOUNCE] lingerd 0.94
I've been meaning to release an update to lingerd since I got it ported to FreeBSD and Solaris... since I can't find the time to do the cosmetic changes that have been in the TODO list for too long, I figure I'll leave those for later. Anyway, here it is... Lingerd version 0.94 has been released; you can find it at http://www.iagora.com/about/software/lingerd/index.html WHAT IS LINGERD? Lingerd is a daemon that greatly improves Apache's scalability by taking over the task of lingering on closing sockets. On dynamic page servers that don't serve their own images (and where keepalives are off), the effect of lingerd on Apache's load is similar to that of a proxy front-end server. CHANGES Lingerd up to 0.93 had been tested under Linux only. This release fixes some compatibility issues to make it work under FreeBSD (other BSDs should work the same), and also buils and runs on Solaris, using a different fd-passing API. -- Roger Espel Llima, [EMAIL PROTECTED] http://www.iagora.com/~espel/index.html
problem with Apache::SSIChain
I am trying to set up a Apache::SSIChain to process the output from a cgi running under Apache::Registry I am using the following line in the conf file: PerlHandler Apache::OutputChain Apache::SSI Apache::Registry The problem is that all of the includes are being inserted at the top of the page rather than where the include call is. So the content of the footer include ends up being inserted before the body. Has anyone seen something like this, or have an idea of what is going wrong? Thanks, Len
Re: Odd problem with Perl sections
On Wed, Oct 24, 2001 at 03:01:25AM -0700, Tom Mornini wrote: in httpd.conf: 1 Perl 2$ErrorLog = |/home/tmornini/Source/ewingz/bin/spread_from_stdin.pl ERROR; 3 /Perl 4 ErrorLog |/home/tmornini/Source/ewingz/bin/spread_from_stdin.pl ERROR Lines 1-3 and 4 should do the same thing. They don't. I was having this exact problem yesterday, with CustomLog and LogFormat. I think it's to do with quotes - try putting single quotes around your $ErrorLog value, so apache will still see it as a quoted string. - carolyn
Re: Odd problem with Perl sections
On Wednesday, October 24, 2001, at 06:38 PM, Carolyn wrote: On Wed, Oct 24, 2001 at 03:01:25AM -0700, Tom Mornini wrote: in httpd.conf: 1 Perl 2$ErrorLog = |/home/tmornini/Source/ewingz/bin/spread_from_stdin.pl ERROR; 3 /Perl 4 ErrorLog |/home/tmornini/Source/ewingz/bin/spread_from_stdin.pl ERROR Lines 1-3 and 4 should do the same thing. They don't. I was having this exact problem yesterday, with CustomLog and LogFormat. I think it's to do with quotes - try putting single quotes around your $ErrorLog value, so apache will still see it as a quoted string. I too am setting CustomLog, and it takes two or three values. So I set @CustomLog and everything is fine. I set LogFormat outside the Perl section and have no need to make it dynamic, so I can't comment here. I worked around this by removing the need for the extra argument for the program I wanted to pipe to, the 'ERROR' in the above example. I just wrapped spread_from_stdin.pl with a shell script, and everything is fine, but I really do suspect that this is a bug. I don't believe that single quotes -vs- double quotes would make a difference. Both things end up a single scalar, and I seriously doubt that Apache can tell the difference... -- -- Tom Mornini -- InfoMania Printing Prepress
Re: tracing memory usage for modules in mod_perl??
Andrei A. Voropaev wrote: Hi! Just wanted to check if it is possible to trace memory usage of each mod_perl modules. It's kind of does not look very realistic, but I do not know the whole truth... Sure you can, arm yourself with B::TerseSize. Look at Apache::Status that uses it, so you can browse symbol tables and learn the size of each OP/datastructure. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Odd problem with Perl sections
On Wed, Oct 24, 2001 at 06:52:13PM -0700, Tom Mornini wrote: I don't believe that single quotes -vs- double quotes would make a difference. Both things end up a single scalar, and I seriously doubt that Apache can tell the difference... well, I meant single *and* double quotes - so the value of $Errorlog is actually quoted itself, like it is in the non-perl-ified directive, because it contains a space. This fixed the problem I was having with LogFormat. But if it's working for you now, cool. -carolyn
Re: namespace-troubles
Not to beat a dead horse, because this subject is well over. Sorry, if I offended anyone. Anyway, I always get and often see others get: You obviously have not read the documentation answer. And wanted to put in my perspective being new to this list and trying to learn mod_perl. I love perl and have more than 15 books on the subject. Here is my list. Programming Perl Programming the Perl DBI Writing Apache Modules Object Oriented Perl = Damian Conway Advanced Perl Programming Perl Cookbook Perl for System Administration Regular Expressions Network Programming with Perl =Lincoln Stein's new book Perl in a Nutshell Web Client Programming Effective Perl Programming Mastering Aogorithms with Perl CGI Programming MySQL mSWL Official Guide to Programming with CGI.pm Learning Perl Programming Web Graphics Perl Core Language Plus the APache Book and some books that cover Perl and PHP on MySql I think your name, Parrin is on or around those books somewhere. I have seen it before. I know I have seen Randalls several times. He is famous for the answer: Stop limiting the limits. whenever you ask a question about limits on Apache. The answer doesn't tell you the answer to your problem. I know now not to use it though. I also have several links to perl sources and yes, the guide. I have read most of these and or something out of them and some of them more than once. I have also read the parts of the guide more than once. I have been doing this for around 3 or 4 years I guess. I tried to tackle mod_perl about a year ago, but with no success and am doing it again with moderate success. I think it is easy when you know something to write out an answer that you think everyone else will know. For instance, Once I had a file locking problem and some one said: Use a semephore file. A day later, I finally found out what a semephore file was. Often when I get an answer, I usually have to go back to the books to find out what it means or how to use it. The turnaround on problems can be days, trying every combination under the sun to see if it works. When I got the previous answer that said: Don't use -w and to use PerlWarn On, it took me about 30 minutes to figure out where to put it. I put it in the startup.pl file. Still hoping that was the right place. Still, when you run into problems with Mod_perl, there are really only a couple of places to look. And just because you have read something, doesn't mean that when a problem arises, the answer will hit you. I often find myself reading old material with more knowledge than when i previously read it and now understand things I didn't have a clue about before. Even though I have read and used a lot of this information, I can tell by the answers and talks you have on the list, that I am still pretty much an amateur. I think when people ask questions, they have not always just opened up an email and sent it out without thought. There is a great fear in that. You don't know what kind of answer you will get, whether you will understand it and have to ask another seemingly stupid question, or get flammed for doing so and never be able to ask a question again. I usually think about it for a couple of hours, try every combination I can think of, and look in every book I think will have something to do with it before tucking my tale and asking a list. Yes, sometimes I will ask before spending the time if I feel I don't have the time to try and find it myself, or have just spent 3 hours trying to solve another problem. Obviously, there are either too many sources or not enough. :) I can't tell. Too many places to look sometimes and not enough others. Sometimes it would be nice to be able to ask stupid questions and get answers instead of clever indirect put downs. Maybe, I just read too much into the emails because of my own insecurities with the language. IT is hard to get a feel for text based conversation. Anyway, I just wanted to put in my two cents and am thinking I might just get flammed for this as well. Should I send it? Sometimes I get this far on emails and just delete them. Cya and thanks John Michael John Michael wrote: I don't know if this will help. I know very litlle about mod perl, but most of the people on this list don't seem to answer questions from beginners. Hmmm. You asked some questions that made it sound like you hadn't read the documentation, and you stil got 3 answers in 24 hours. One thing you should consider is that not everyone here is in the same time zone. I think you might try adding: use subs qw(main); in the top of your script. or instead of main() use main() That's probably not it. The difference between mail() and main() is that main() circumvents prototypes, as documented in the perlsub man page. If that doesn't work, you will probably need to make the lib a package and import it into your fetch.pl program. That probably *is* the answer, and a good programming practice for any
Re: Odd problem with Perl sections
On Wednesday, October 24, 2001, at 07:25 PM, Carolyn Hicks wrote: On Wed, Oct 24, 2001 at 06:52:13PM -0700, Tom Mornini wrote: I don't believe that single quotes -vs- double quotes would make a difference. Both things end up a single scalar, and I seriously doubt that Apache can tell the difference... well, I meant single *and* double quotes - so the value of $Errorlog is actually quoted itself, like it is in the non-perl-ified directive, because it contains a space. This fixed the problem I was having with LogFormat. But if it's working for you now, cool. Oh! I see now... :-) Thanks, that's very interesting. I completely misunderstood your first response, sorry about that! -- -- Tom Mornini -- InfoMania Printing Prepress
Re: namespace-troubles
Sorry if I came off sounding harsh. I spend a lot of my personal time answering newbie questions on this list, and it bothers me when people say that newbies don't get helped here. They generally get a lot of help here. If someone says it's in the guide and you can't find it, ask for a link to the relevant section. If you read that section and still don't get it, ask more questions. Sending people links to the proper docs in response to questions when possible is a simple matter of efficiency. - Perrin
Bit of an oddity configuring perl (fwd) (fwd)
Should be fairly simple: Configure a few locations w/in the perl
section of httpd.conf. The code seems to run, exept that naming the
first section /cdr/Data gives me the output from Cdr::Welcome, rather
than the Cdr::Data module. Changing the name from cdr/Data to
cdr/Foo in the config file fixes the problem; changing it to cdr/Bar
breaks things again. Aside from server-status and server-info these are
the only locations in the config file; the only dir's in the file are
serverroot and htdocs -- which don't seem to cause any problem.
The really annoying thing is that all I get back is a lack of error
messages and the contents of the /cdr location when accessing the
/cdr/Data (/cdr/Menu and /cdr work fine). Aside from gremlins or an
easter egg for URI's named Foo, anyone know of a decent reference
for this?
thanx,
sl
$Location{'/cdr/Data'} =
{
SetHandler = 'perl-script',
SetEnvIf=
[
[ 'Cookie', 'Eastern', 'TZ=US/Eastern' ],
[ 'Cookie', 'Central', 'TZ=US/Central' ],
[ 'Cookie', 'Mountain', 'TZ=US/Mountain' ],
[ 'Cookie', 'Pacific', 'TZ=US/Pacific' ],
[ 'Referer', 'Central', 'TZ=US/Central' ],
[ 'Referer', 'Eastern', 'TZ=US/Eastern' ],
[ 'Referer', 'Mountain', 'TZ=US/Mountain' ],
[ 'Referer', 'Pacific', 'TZ=US/Pacific' ],
],
PerlHandler = 'Cdr::Data',
};
# welcome screen, authentication is handled
# here also via Apache::AuthNetLDAP which
# is configured here.
$Location{'/cdr'} =
{
SetHandler = 'perl-script',
PerlSetEnv = BASEURL http://$host:$Port/cdr;,
PerlHandler = 'Cdr::Welcome',
};
$Location{'/cdr/Top'} =
{
SetHandler = 'perl-script',
PerlHandler = 'Cdr::Top',
};
$Location{'/cdr/Menu'} =
{
SetHandler = 'perl-script',
PerlHandler = 'Cdr::Menu',
};
--
Steven Lembark 2930 W. Palmer
Workhorse Computing Chicago, IL 60647
+1 800 762 1582
Re: Excellent article on Apache/mod_perl at eToys
On Thu, 18 Oct 2001 19:11:04 -0700 (PDT) Andrew Ho [EMAIL PROTECTED] wrote: I checked the list archives and it didn't look like this had been posted yet. For those of you who haven't seen it yet... a great read on perl.com about the Apache/mod_perl setup at eToys, co-authored by our own mod_perl regular contributer Perrin Harkins. http://www.perl.com/pub/a/2001/10/17/etoys.html I've translated this article into Japanese, and you can get it on http://bulknews.net/lib/doc-ja/etoys.ja.html http://bulknews.net/lib/doc-ja/etoys.ja.pod Just wanted to let you know. Thanks for the excellent article, Perrin! -- Tatsuhiko Miyagawa [EMAIL PROTECTED]
Re: Odd problem with Perl sections
On Wednesday, October 24, 2001, at 11:38 AM, Scott Lanning wrote: On Wed, 24 Oct 2001, Tom Mornini wrote: 1 Perl 2$ErrorLog = |/home/tmornini/Source/ewingz/bin/spread_from_stdin.pl ERROR; 3 /Perl 4 ErrorLog |/home/tmornini/Source/ewingz/bin/spread_from_stdin.pl ERROR [snip] When I use the Perl section (which I need to allow the path to spread_from_stdin.pl to be dynamic at runtime) I receive this error: [Wed Oct 24 09:52:25 2001] [error] Perl: ErrorLog takes one argument, The filename of the error log On line 4, you passed one argument delimited by quotation marks. On line 2, you passed two arguments: 1) |/home/tmornini/Source/ewingz/bin/spread_from_stdin.pl 2) ERROR so it seems you need to escape the space between them somehow (I guess by a backslash, or put single quotes around the double quotes, but I didn't test it). Yes, you're the second person to mention it, but you said it more clearly... This will work... $ErrorLog = q[|/home/tmornini/Source/ewingz/bin/spread_from_stdin.pl ERROR]; or qq[] if you need interpolation. (which I do) -- -- Tom Mornini -- InfoMania Printing Prepress
Again DSO-mod_perl and leaking on restart: FreeBSD
Hi, some weeks ago here was the discussion about DSO-mod_perl and leaking; as far as I understand it the solution was, that on SOME platforms (solaris) mod_perl should be build as static. It seems that FreeBSD is such a platform ;-) I build Apache from the Ports-Collection with mod-ssl -- /usr/ports/www/apache13-modssl -- (with 1.3.20 and 1.3.22) and manually Perl 5.6.1 (NO mymalloc, no compatibility, with mymalloc also tested) and mod_perl 1.26 as DSO with APXS. My mod_perl-Application has a global and resident hash, about 18 MB, which is build in the startup-script. At normal startup, it seems that mod_perl requires TWICE the amount of this hash, and each restart (also graceful) it eats ~18 MB. 1 GB is fast full ;-) The mod_perl from Ports Collection is build also as DSO and has the same problem (with old Perl replaced by 5.6.1). Has someone mod_perl on FreeBSD WITH DSO and without leaking running? If not possible it might be good to include a warning in the Makefiles or mod_perl-Guide etc. I prefer to build Apache from the Ports collection, so at next I'll try to create a Port with static mod_perl ... Ciao Alvar PS: #perl -V Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=freebsd, osvers=4.4-stable, archname=i386-freebsd uname='freebsd gnarzelwicht.delirium-arts.de 4.4-stable freebsd 4.4-stable #8: sat oct 6 13:55:41 cest 2001 [EMAIL PROTECTED]:usrobjusrsrcsysmykernel2 i386 ' config_args='' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include', optimize='-O3 -march=k6 -funroll-loops -fexpensive-optimizations -malign-double', cppflags='-fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='2.95.3 20010315 (release) [FreeBSD]', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, usemymalloc=n, prototype=define Linker and Libraries: ld='cc', ldflags ='-Wl,-E -L/usr/local/lib' libpth=/usr/lib /usr/local/lib libs=-lgdbm -ldb -lm -lc -lcrypt -liconv -lutil perllibs=-lm -lc -lcrypt -liconv -lutil libc=, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-DPIC -fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under freebsd Compiled at Oct 23 2001 17:37:29 @INC: /usr/lib/perl5/5.6.1/i386-freebsd /usr/lib/perl5/5.6.1 /usr/lib/perl5/site_perl/5.6.1/i386-freebsd /usr/lib/perl5/site_perl/5.6.1 /usr/lib/perl5/site_perl .
Re: Again DSO-mod_perl and leaking on restart: FreeBSD
Hi, It would be interesting to hear whether you have the same results with the stock Perl version distributed with FreeBSD (built without PERL_THREADED defined, since that experimental stuff was removed from FreeBSD with good reason). with perl 5.6.1 and my Perl isn't threaded :) That's what the p5-apache port did. I added the mod_perl port _specifically_ to make mod_perl available to FreeBSD admins dynamically. but it's build as DSO and I guess this makes the troubles. i prefer DSO and ports too, but i guess that DSO is the problem. Also the standard perl of FreeBSD is 5.005 -- which is really leaking memory and not up to date ;=) so i want to use 5.6.1 -- on my test machine i replaced it with 5.6.1, on production server i installed a second perl because it seems that it was not the best idea to replace the standard perl version ... Ciao Alvar
Re: Again DSO-mod_perl and leaking on restart: FreeBSD
Hi, It kinda feels like you didn't absorb any of the contents of my reply. :-) ehm, ups sorry -- perhaps i misunderstand you ;) (oh yes, my english is bad :( ) Let me try a different approach. What do you want me to do? it was mainly a message to the mod_perl mailinglist, CC to you because you maintain the ports and maybe heard about the problem. about two months ago in the list there was a discussion about building mod_perl as DSO and the result was, that on some platforms it leaks memory if build as DSO. Ciao Alvar
Re: Apache::Compress - any caveats?
Hi there, On Wed, 24 Oct 2001, Mark Maunder wrote: I noticed that there are very few sites out there using Content-Encoding: gzip - in fact yahoo was the only one I could find. Is there a reason for this I think because many browsers claim to accept gzip encoding and then fail to cope with it. 73, Ged.
Re: Apache::Compress - any caveats?
Ged Haywood wrote: Hi there, On Wed, 24 Oct 2001, Mark Maunder wrote: I noticed that there are very few sites out there using Content-Encoding: gzip - in fact yahoo was the only one I could find. Is there a reason for this I think because many browsers claim to accept gzip encoding and then fail to cope with it. The only bug I have noticed is Netscape 4.7 which does not like anything other than HTML to be compressed. So the only thing I'm compressing is text/html. I dont know of any browsers that wont accept compressed html (so far).
Re: problem with Apache::SSIChain
LPorcano wrote: I am trying to set up a Apache::SSIChain to process the output from a cgi running under Apache::Registry I am using the following line in the conf file: PerlHandler Apache::OutputChain Apache::SSI Apache::Registry Shouldn't that be PerlHandler Apache::OutputChain Apache::SSIChain Apache::Registry instead?
Re: problem with Apache::SSIChain
Yeah, sorry that was a typo in the email. It is actually Apache::SSIChain in the conf file. Len - Original Message - From: Perrin Harkins [EMAIL PROTECTED] To: LPorcano [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, October 25, 2001 9:52 AM Subject: Re: problem with Apache::SSIChain LPorcano wrote: I am trying to set up a Apache::SSIChain to process the output from a cgi running under Apache::Registry I am using the following line in the conf file: PerlHandler Apache::OutputChain Apache::SSI Apache::Registry Shouldn't that be PerlHandler Apache::OutputChain Apache::SSIChain Apache::Registry instead?
Re: Excellent article on Apache/mod_perl at eToys
On Tue, 2001-10-23 at 12:31, Dave Hodgkinson wrote: Nathan Torkington [EMAIL PROTECTED] writes: Is there a nice graphicy map of what actually constitutes J2EE onto which we can overlay the relevant perl bitz? Something like this: http://www.onjava.com/pub/a/onjava/api_map/ http://java.sun.com/j2ee/ I wonder if such a P2EE project should build on CORBA just as J2EE does? Is interoperability with J2EE a goal? The other approach is to get the Perl language ported to the JVM. I know some work has been put into that. In this case it's important to be able to access the Java API's as easily as it is in Java. I lean toward the second approach since it would give P2EE a faster start, building on already existent frameworks. Eg. you could begin writing EJB components in perl immediately. Matt -- pgp: http://www.geocities.com/matthewbk/pubkeyw.txt PGP signature
Re: [OT] excellent modperl/etoys article by Perrin revisited
I was told over the weekend by one of my old eToys cow-orkers that the current incarnation of www.etoys.com isn't running our old code. Leave it to KB to buy all the code then not bother to use it. I understand that's also the reason they couldn't be bothered to migrate the old accounts over. Brian Nilsen [EMAIL PROTECTED] On Thu, 25 Oct 2001, Gunther Birznieks wrote: I saw an article in today's ComputerWorld that indicates the technology et al for eToys was bought by another toy firm (KB) and they plan to put it up to sell toys for this holiday season again. http://www.computerworld.com/cwi/story/0,1199,NAV47_STO65008,00.html Perrin or others involved in the old eToys (or anyone in the new eToys) -- does anyone know if this is the same mod_perl technology you guys wrote? I think it will make an interesting success story follow up if it is successful because it would also show how easy it was for the intellectual property written in mod_perl to be resold and reintegrated into another IT infrastructure which would make VCs happy (ie they would think more about being able to fund projects based on mod_perl if they know they could always resell the IP). Thanks, Gunther __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
Re: [OT] excellent modperl/etoys article by Perrin revisited
At 12:26 PM 10/25/2001 +0800, Gunther Birznieks wrote: I saw an article in today's ComputerWorld that indicates the technology et al for eToys was bought by another toy firm (KB) and they plan to put it up to sell toys for this holiday season again. http://www.computerworld.com/cwi/story/0,1199,NAV47_STO65008,00.html Perrin or others involved in the old eToys (or anyone in the new eToys) -- does anyone know if this is the same mod_perl technology you guys wrote? Well, I'm just talking off the top of my head, but my interpretation is that the Web site relies on eToys software purchased at the bankruptcy auction and on KB Toys' existing IT infrastructure means that it's the software Perrin et al. wrote, running on KB's hardware. I can't imagine that to mean that they rewrote the software. If so, that just validates the decisions the eToys design team made. Even more kudos Perrin! :-) Drew Taylor JA[P|m_p|SQL]H http://www.drewtaylor.com/ Just Another Perl|mod_perl|SQL Hacker mailto:[EMAIL PROTECTED] *** God bless America! *** ICQ: 135298242
Re: [OT] excellent modperl/etoys article by Perrin revisited
Perrin or others involved in the old eToys (or anyone in the new Toys) -- does anyone know if this is the same mod_perl technology you guys wrote? I'm not involved in that anymore, so I don't have first-hand information. However, a brief look at the site makes me think they are not using any of what we wrote. The URL structures and query args (i.e. the public API of the site) are all very different. I think it will make an interesting success story follow up if it is successful because it would also show how easy it was for the intellectual property written in mod_perl to be resold and reintegrated into another IT infrastructure which would make VCs happy (ie they would think more about being able to fund projects based on mod_perl if they know they could always resell the IP). You have to remember that what we wrote was a specific application, not a generic store or application server. That code would only be useful if you wanted a store that did everything (data model, navigation, order processing) exactly the way we did. I very much doubt KB is that similar. Also, the documentation was great for an in-house project but not enough for a packaged commercial app. There was a basic shared knowledge assumed in most of it about the business goals and environment. Keep in mind that we wrote very little infrastructure code - no more than I would expect a J2EE project this large to write. The infrastructure came from CPAN, Apache, etc. and is known to be very portable. I suspect that KB has a team who supports their site and they chose to use the technologies they already have in place. People hate change, and looking at a foreign codebase, possibly in a language you don't know, is daunting. It would be the same thing if someone walked into an ASP shop with a bundle of WebLogic code and said make it run, and work with our legacy systems, with these changes, by Christmas. And don't stop supporting our regular site. Oh, and we didn't hire any of the developers who wrote it or the business people who told them what to write, so you'll just have to read the source if you have questions that aren't in the documentation. Doesn't sound that appealing, does it? - Perrin
Sanity check: statically linking binary extensions like GD in to httpd
I'm seeking a sanity check on statically linked binary extensions in
with httpd. I've built what I want, but the build is not easily
automatable, and I'm hoping I missed an easy alternative somewhere.
Background: we have a .png that we want to generate on the fly with up
to several thousand filled circles, dots, lines etc., using GD.pm, so
I've shoe horned it and libpng into the httpd to get a minor performance
improvement (we want to put this image on almost every page, and caching
can help, but we need to be able to draw it *fast*, and all those calls
in to a dynamically linked library cause noticable overhead[1].) I'd
also like to write this up.
First, I tried to build GD as a static extension:
perl Makefile.PL LINKTYPE=static
make
make test
...snip...
cat /usr/local/lib/perl5/5.6.1/i686-linux/auto/DynaLoader/extralibs.ld
blib/arch/auto/GD/extralibs.all
cat /usr/local/lib/perl5/site_perl/5.6.1/i686-linux/auto/libapreq/extralibs.ld
blib/arch/auto/GD/extralibs.all
cat blib/arch/auto/GD/extralibs.ld blib/arch/auto/GD/extralibs.all
cc -L/usr/local/lib -rdynamic -o perl -O2 ./perlmain.o GD.o blib/arch/auto/GD/GD.a
/usr/local/lib/perl5/site_perl/5.6.1/i686-linux/auto/libapreq/libapreq.a
/usr/local/lib/perl5/5.6.1/i686-linux/auto/DynaLoader/DynaLoader.a
/usr/local/lib/perl5/5.6.1/i686-linux/CORE/libperl.a `cat
blib/arch/auto/GD/extralibs.all` -lnsl -ldl -lm -lc -lposix -lcrypt -lutil
./perlmain.o: In function `xs_init':
./perlmain.o(.text+0x9f): undefined reference to `boot_libapreq'
collect2: ld returned 1 exit status
...snip...
Doing this attempts to build a static perl, which fails with the below
error message. It seems that the LINKTYPE=static is forcing ExtUtils to
think that *all* static-looking extensions in site_perl/ should be
static, not just those mentioned in $Config{static_exts} (which is ' '
here). I'm assuming that libapreq isn't primed to be a static extension
because I'm running a dynamic perl, but this may be a bug. Whether or
not it's a bug, it seems like it's awkward.
So I mved site_perl off to the side for a moment and it builds and
installs fine. libapreq is not statically linked in to my perl binary
because it's only needed for mod_perl use, and mod_perl links it
(statically) in to the httpd.
QUESTION 1: how can I build a static extension for use with mod_perl
that you *don't* want in your normal perl, and how do I get it to ignore
dynamic extension dependancies like the libapreq one? Building a perl
by another name, like gdperl, works (after the mv site_perl), but
doesn't build an equivalent libgdperl.a (see question 2, below).
gdperl is a nice abbreviation though ;).
Anyway, after getting GD.a installed in to site_perl (and giving up on
gdperl, since no libgdperl.a was built) I configure mod_perl like so:
perl Makefile.PL \
APACHE_SRC=../apache-1.3.22/src \
DO_HTTPD=1 \
USE_APACI=1 \
EVERYTHING=1 \
PERL_STATIC_EXTS=GD \
APACHE_PREFIX=$HOME/gdwww \
PREFIX=$HOME/gdwww
and the build fails because GD.a isn't being linked in, and libperl.a
doesn't contain the object modules from GD.a.
** QUESTION 2: how to get libperl.a to contain the guts of GD? Or,
alternatively, how do I tell mod_perl that I want GD.a linked in
(without hacking apaci/perl.module)? Even when I do a make -f
Makefile.aperl inst_perl, no new libperl.a is installed. I could do the
old trick of cpio-ing GD in to the perl distro, but there must be a
better way I'm not seeing. PERL
So, I tweaked mod_perl's apaci/perl.module to have the line:
LIBS=$LIBS /usr/local/lib/perl5/site_perl/5.6.1/i686-linux/auto/GD/GD.a -lgd
-ljpeg -lpng
near the end and I get a nice, shiny statically linked httpd with all of
the require libs. YAY!
** QUESTION 3: What is the recommended way to link in external .a and .o
modules like libpng.a?
Hopefully, there's a left turn in Albuquerque I should have taken that
someone can point out to me...
Thanks,
Barrie
[1] which means we may head to C for some of the core routines, but that
just moves the linking issues up a level.
Re: Excellent article on Apache/mod_perl at eToys
I suppose I should point out that perl.com is always interested in mod_perl articles. If you've learned lessons that others could benefit from, contact the perl.com editor, Simon Cozens [EMAIL PROTECTED]. Nat
ANNOUNCE: Apache::OpenIndex 1.03
OpenIndex provides a file manager for an Apache modperl web site from a web browser. OpenIndex also provides the same functionality as autoindex, therefore it can be used to both manage and navigate a web site. An Apache::OpenIndex (OpenIndex-1.03.tar.gz) update was uploaded to CPAN on 25 Oct 2001. The module can also be downloaded at: http://www.xorgate.com/Apache/OpenIndex/ OpenIndex now supports Cascading Style Sheets and individual HTML tab configurable attributes. For example, you can now add TAG attributes like: TAG attributes or add TAG text, like: TAG text /TAG Two new directives were added to support this feature: IndexHtmlTagtagattributes IndexHtmlText tagtext The following tags have attribute support: head style frameset noframe body table form font input textarea th tr hr h1 h2 h3 td a p The following tags have text support: frame noframe style The FoldersFirst index option was also added. Again, a demo is available at: http://www.xorgate.com/Apache/OpenIndex/demo Enjoy:) ++ | George Sanderson [EMAIL PROTECTED] | http://www.xorgate.com ++
Funny headers in modperl-site messages
Does anyone know why messages sent to the modperl-site list have modperl-cvs in their headers, like the following? List-Help: mailto:[EMAIL PROTECTED] List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Post: mailto:[EMAIL PROTECTED] -Ken
