Re: News regarding mod_perl returning empty pages
On Tue, Aug 25, 2009 at 7:20 PM, Igor Chudovichu...@gmail.com wrote: My new perlbal.conf is included: REATE POOL dynamic pool dynamic add 127.0.0.1:10080 CREATE SERVICE balancer SET listen = 0.0.0.0:80 SET role = reverse_proxy SET pool = dynamic SET persist_client = on SET persist_backend = off SET verify_backend = on With verify_backend = on, perlbal makes an OPTIONS request to the mod_perl server. That request usually returns an empty 200, which in other scenarios could be viewed as a blank page. How perlbal would send that back to the client is something I don't know. But I would consider disabling that option as it doubles the number of total requests to the backend mod_perl server. That's just my opinion though, changing that failure could cause other failure modes to surface. If you want to use that option, you should write a mod_perl handler that answers to a verify_backend url (see the perlbal docs) and returns a few characters of text back to perlbal. If you see those characters in your blank screens - that's the problem. Although I'm skeptical that is what is happening.
Re: mod_perl2 interactive startup
On Tue 25 Aug 2009, ama...@solutionsforprogress.com wrote: Unfortunately using restart_count does not address my issue. In the http.conf I have the following: ... PerlConfigRequire conf/startup.pl ... My test startup.pl has this: our $INPUT; print STDERR Input:; $INPUT = STDIN; print STDERR you entered $INPUT; My issue is during the first start everything works as I need it to, Input: is printed out to the terminal and the script waits for input. The problem is for the automatic restart everything is tied to the log files. Everything printed to STDERR goes into the logs and a user cannot enter any input. For the restart how can I print messages and prompt for input? Don't know if it actually works, but how about POSIX::dup2()ing STDERR/STDIN (or better opening /dev/tty and use this one for reading and writing) to well known file descriptors (say 1000, 1001) when restart_count==0. Then when restart_count0 you should be able to use them. Torsten -- Need professional mod_perl support? Just hire me: torsten.foert...@gmx.net
Re: mod_perl on win32
I'd suggest to get your mp2 up with the following stack: Apache22 Windows binary ActivePerl binary precompiled mod_perl2 + libapreq2 from the repo Michiel Beijen wrote: Hi all, I'd like to know if it's possible to build mod_perl on Win32; I'd like to use mod_perl with StrawberryPerl. It seems to be that the only way that could be done is to compile Apache also with MinGW, and that's not possible because of limited support for Windows Shared Memory in MinGW. Also if you'd try to compile mod_perl it will try to run ./configure on the Apache sources but that will fail on Win32 because 1. there is no Configure in the win32 Apache sources and 2. Windows will try to execute . which is not exactly an executable file... Does anyone have pointers or tips? Thanks in advance,
RFC: Apache2::CloseKeepAlive
I'm working toward contributing a module with this working title to CPAN, and would like your comments and advice. The short story is that it's a mod_perl2 mechanism for optimizing the KeepAlive option in the Apache2 server. The long story is at http://www.animalhead.com/CloseKeepAlive.html I'm tentatively convinced it's worth contributing, but you're welcome to tell me why it's not. For sure, your advice on how to improve it will be very welcome. Specifically: • What CPAN module(s) is (are) most like this one, to use as model(s) for how to package, test, and install it? • The plan is to use Module::Build and Apache::Test. What else or something different? • Is something as specialized as this worth including in the GP Perl libraries? Or is it better to just ask where the mod_perl2 library is? • Is inclusion in the GP Perl libraries a prerequisite or assumption of Module::Build or of CPAN? In addition to where to put the module itself, it needs a place to put a companion DB-building app and a place for the resulting DB. These are not standard features of a module installation. Probably I just ask the user where they should go? If so, how do I use the answers? Thanks for being there, cmac
Re: News regarding mod_perl returning empty pages
Fred, thanks. I am afraid that verify_backend is more of an expensive distraction, than something actually useful. At this point in time I will try setting both persist_backend and verify_backend to off. I am also considering changing MaxRequestsPerChild and setting it to something like 1,000. None of this really solves the problem, but it might alleviate it very considerably. Thank you very much. Your help was invaluable and assisted me in keeping a level head in dealing with this problem. .
Re: RFC: Apache2::CloseKeepAlive
On Wed, Aug 26, 2009 at 6:43 AM, cr...@animalhead.com wrote: I'm tentatively convinced it's worth contributing, but you're welcome to tell me why it's not. I think that setting a very short Keep-Alive timeout would be almost as good. More importantly, you shouldn't serve any static files from mod_perl. You should serve those from a proxy instead. However, I don't see any problem with releasing your code. It's an interesting idea and shows a novel use of IPC::MMA. • The plan is to use Module::Build and Apache::Test. What else or something different? Those are fine. • Is something as specialized as this worth including in the GP Perl libraries? Or is it better to just ask where the mod_perl2 library is? What's GP Perl? In addition to where to put the module itself, it needs a place to put a companion DB-building app and a place for the resulting DB. These are not standard features of a module installation. Probably I just ask the user where they should go? If so, how do I use the answers? You can ask on the module authors list, but I think you'll find some examples of modules with executable scripts if you poke around CPAN a little. LWP comes with some. - Perrin
Re: portability of mod_perl for other web servers/apps
On Tue, Aug 25, 2009 at 3:00 PM, dbadhanidbadh...@yahoo.com wrote: This may sound far fetched, but has anyone tried porting mod_perl for web servers other than Apache. No, and it wouldn't really work. A generic approach to running persistent code already exists in the form of FastCGI. The rest of mod_perl is a perl interface to the Apache API, which makes it unsuitable for other web servers. Basically, I am looking for integrating some of mod_perl functionality in some high performance middleware, basically to provide a way to customized, scriptable request processing in the request processing engine. You could look at FastCGI, or embedding perl directly. - Perrin
Re: News regarding mod_perl returning empty pages
Igor, Why don't you try logging the request size from your mod_perl server? If it turns out that it knows when a request is zero bytes, you can just kill the process in a cleanup handler. Also, if you identify the PID of the broken process in this way, you can look back through the logs to see what it did on the request before it was broken. - Perrin
Re: RFC: Apache2::CloseKeepAlive
cr...@animalhead.com wrote: I'm working toward contributing a module with this working title to CPAN, and would like your comments and advice. A non-code comment, but there seems to be some consternation about the same terms as perl itself license. See the link below: http://perlbuzz.com/2009/07/help-end-licensing-under-same-terms-as-perl-itself.html Adam
Re: mod_perl2 interactive startup
On Tue, Aug 18, 2009 at 4:54 PM, ama...@solutionsforprogress.com wrote: During the mod_perl2 startup this feature works fine at first but mod_perl2 always does a restart and during the second restart STDERR is being redirected to the log files and STDIN is ignored. I suggest stashing the data somewhere and picking it up during restart, like an environment variable or shared memory or a file. - Perrin
Re: News regarding mod_perl returning empty pages
On Wed, Aug 26, 2009 at 8:58 AM, Perrin Harkins phark...@gmail.com wrote: Igor, Why don't you try logging the request size from your mod_perl server? If it turns out that it knows when a request is zero bytes, you can just kill the process in a cleanup handler. Do you refer to the response size, as opposed to request size? If so... I like your idea. How would I do that? Also, if you identify the PID of the broken process in this way, you can look back through the logs to see what it did on the request before it was broken. Yes, it is a very good idea indeed.
Re: News regarding mod_perl returning empty pages
On Wed, Aug 26, 2009 at 11:12 AM, Igor Chudovichu...@gmail.com wrote: Do you refer to the response size, as opposed to request size? Yes. If so... I like your idea. How would I do that? Just read the logging section of the apache docs. It's a common part of the access log. - Perrin
Re: RFC: Apache2::CloseKeepAlive
On Aug 26, 2009, at 7:03 AM, Perrin Harkins wrote: What's GP Perl? The general purpose Perl library is headed at /usr/local/lib/perl5 on my system. What I was asking is whether there's any reason to put Apache2::CloseKeepAlive in it, being as it's so specialized, or just copy it to a mod_perl2-specific library (/usr/local/apache2/plib on my system). Maybe the latter if the user says such a thing exists, else the former? cmac
Re: RFC: Apache2::CloseKeepAlive
On Wed, Aug 26, 2009 at 11:41 AM, cr...@animalhead.com wrote: The general purpose Perl library is headed at /usr/local/lib/perl5 on my system. What I was asking is whether there's any reason to put Apache2::CloseKeepAlive in it, being as it's so specialized, or just copy it to a mod_perl2-specific library (/usr/local/apache2/plib on my system). Maybe the latter if the user says such a thing exists, else the former? You don't get to choose that. You just do a standard Module::Build distribution, and if people want to install your module somewhere outside of the site_lib, they specify that at install time. - Perrin
Re: RFC: Apache2::CloseKeepAlive
On Aug 26, 2009, at 7:39 AM, Adam Prime wrote: A non-code comment, but there seems to be some consternation about the same terms as perl itself license. See the link below: http://perlbuzz.com/2009/07/help-end-licensing-under-same-terms-as- perl-itself.html Inside many programmers, nascent lawyers lurk? The linked-to CPAN Licensing Guidelines http://www.perlfoundation.org/cpan_licensing_guidelines was easier to read and didn't cut off the right sides of code segments. I modified the end of http://www.animalhead.com/CloseKeepAlive.html accordingly. Thanks, cmac
Re: RFC: Apache2::CloseKeepAlive
On Aug 26, 2009, at 9:05 AM, Perrin Harkins wrote: On Wed, Aug 26, 2009 at 11:41 AM, cr...@animalhead.com wrote: The general purpose Perl library is headed at /usr/local/lib/perl5 on my system. What I was asking is whether there's any reason to put Apache2::CloseKeepAlive in it, being as it's so specialized, or just copy it to a mod_perl2-specific library (/usr/local/ apache2/plib on my system). Maybe the latter if the user says such a thing exists, else the former? You don't get to choose that. You just do a standard Module::Build distribution, and if people want to install your module somewhere outside of the site_lib, they specify that at install time. - Perrin How does one specify that? It sounds like esoteric knowledge that only a few users will know, and I'd like to empower people not to clog up their GP Perl library with a module that can be used in exactly one place.
Re: RFC: Apache2::CloseKeepAlive
On Wed, Aug 26, 2009 at 12:21 PM, cr...@animalhead.com wrote: How does one specify that? It sounds like esoteric knowledge that only a few users will know, and I'd like to empower people not to clog up their GP Perl library with a module that can be used in exactly one place. It's in the docs for Module::Build. Seriously, you have no control over where users install your module. Attempting to control it is against the principles of CPAN distributions. - Perrin
Re: RFC: Apache2::CloseKeepAlive
Including a note about how to do something in an installation dialog, for people who wouldn't otherwise know, is not controlling anything. If that's against CPAN principles, the principles need some work! cmac On Aug 26, 2009, at 9:30 AM, Perrin Harkins wrote: On Wed, Aug 26, 2009 at 12:21 PM, cr...@animalhead.com wrote: How does one specify that? It sounds like esoteric knowledge that only a few users will know, and I'd like to empower people not to clog up their GP Perl library with a module that can be used in exactly one place. It's in the docs for Module::Build. Seriously, you have no control over where users install your module. Attempting to control it is against the principles of CPAN distributions. - Perrin
Re: RFC: Apache2::CloseKeepAlive
Seriously, this is not something you need to be concerned about. There are dozens of places for people to get information about how to install CPAN modules. Most people use the CPAN shell and set it up to put things where they want them. - Perrin On Wed, Aug 26, 2009 at 1:31 PM, cr...@animalhead.com wrote: Including a note about how to do something in an installation dialog, for people who wouldn't otherwise know, is not controlling anything. If that's against CPAN principles, the principles need some work! cmac On Aug 26, 2009, at 9:30 AM, Perrin Harkins wrote: On Wed, Aug 26, 2009 at 12:21 PM, cr...@animalhead.com wrote: How does one specify that? It sounds like esoteric knowledge that only a few users will know, and I'd like to empower people not to clog up their GP Perl library with a module that can be used in exactly one place. It's in the docs for Module::Build. Seriously, you have no control over where users install your module. Attempting to control it is against the principles of CPAN distributions. - Perrin
Re: mod_perl on win32
Foo JH wrote: I'd suggest to get your mp2 up with the following stack: Apache22 Windows binary ActivePerl binary precompiled mod_perl2 + libapreq2 from the repo That would be the easy way, right ;-) The thing is, my project uses a software bundle which includes Apache and Strawberry for the Windows installer. Due to licensing requirements you could not bundle ActiveState in an open source product; therefore the Strawberry requirement. It is just too bad that ApachePerl is not alive anymore. Any tips for compiling mod_perl with Strawberry are still welcome! Regards, Michiel
Re: RFC: Apache2::CloseKeepAlive
cr...@animalhead.com wrote: Including a note about how to do something in an installation dialog, for people who wouldn't otherwise know, is not controlling anything. Please don't put a dialog in your installation process! CPAN is supposed to be automatic after it's been configured. There are some rare occasions where it makes sense to ask some questions, but where you want the module installed is not one of them. CPAN takes care of that. -- Michael Peters Plus Three, LP
Re: News regarding mod_perl returning empty pages
On Wed, Aug 26, 2009 at 8:16 AM, Perrin Harkinsphark...@gmail.com wrote: On Wed, Aug 26, 2009 at 11:12 AM, Igor Chudovichu...@gmail.com wrote: Do you refer to the response size, as opposed to request size? Yes. If so... I like your idea. How would I do that? Just read the logging section of the apache docs. It's a common part of the access log. This is a good reference: http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlLogHandler
Re: RFC: Apache2::CloseKeepAlive
The installation process needs to know at least: 1. where the accompanying DB-building script should go 2. where the DB that the app builds should go How can such necessary things be determined, other than by asking the user? I was just going to add a note before or after these two queries, that if they have a mod_perl2 library and want the module to go there, they should do this. As I just wrote to Perrin off-list, since only a tiny fraction of CPAN downloads are mod_perl2 modules, no one can configure CPAN for a mod_perl2 library. Perhaps my attitude toward installation dialogs has been warped by recent experience with my previous CPAN module IPC::MMA. The install for version 0.54 contained no prompts. Its results came out 75% unknown, because few test environments included a necessary C library 'mm'. One of the chief testers suggested I should add Devel::CheckLib to Makefile.PL. So now if Makefile.PL doesn't find 'mm' in /usr/local/lib, it prompts the user to enter the path to 'mm', which is then passed to Devel::CheckLib. The query is accompanied by a note showing the URL from which 'mm' can be downloaded. On the other hand, my latest version 0.58 has only been tested by one tester, a week after uploading it. Maybe that's because of the new query in Makefile.PL! Best Regards, cmac On Aug 26, 2009, at 10:44 AM, Michael Peters wrote: cr...@animalhead.com wrote: Including a note about how to do something in an installation dialog, for people who wouldn't otherwise know, is not controlling anything. Please don't put a dialog in your installation process! CPAN is supposed to be automatic after it's been configured. There are some rare occasions where it makes sense to ask some questions, but where you want the module installed is not one of them. CPAN takes care of that. -- Michael Peters Plus Three, LP
Re: RFC: Apache2::CloseKeepAlive
cr...@animalhead.com wrote: The installation process needs to know at least: 1. where the accompanying DB-building script should go Module::Build knows where to put bin/ or script/ files and it does so according to how Perl and CPAN are configured. I assume EU::MM does too. 2. where the DB that the app builds should go That's probably something your application should allow to be specified, either a command line option to the script or an option to the module, or both. How can such necessary things be determined, other than by asking the user? If it's a run time option (and can be changed or multiple programs can use this and thus want different values) don't ask for it at install time. I was just going to add a note before or after these two queries, that if they have a mod_perl2 library and want the module to go there, they should do this. Putting extra docs in your module is ok, but I personally wouldn't repeat the docs that are already out there. As I just wrote to Perrin off-list, since only a tiny fraction of CPAN downloads are mod_perl2 modules, no one can configure CPAN for a mod_perl2 library. All perl libraries should go in the same place IMO. Whether it's Apache specific, or GTK or something else. I don't want to have to mess with @INC just because someone put something someplace non-standard. So now if Makefile.PL doesn't find 'mm' in /usr/local/lib, it prompts the user to enter the path to 'mm', which is then passed to Devel::CheckLib. The query is accompanied by a note showing the URL from which 'mm' can be downloaded. Personally, I'd just bomb out if you can't find the lib (and Devel::CheckLib is good for that). Give the user a message that you can't find the library and then exit. I doubt that someone who has a library that's not in the system libs will know where it is, and if they do they can just as easily set LD_LIBRARY_PATH themselves. On the other hand, my latest version 0.58 has only been tested by one tester, a week after uploading it. Maybe that's because of the new query in Makefile.PL! That's why prompts are evil. Automated tests won't work. So just bomb out and at least you'll get lots of UNKNOWN test results which is better than nothing :) -- Michael Peters Plus Three, LP
Re: portability of mod_perl for other web servers/apps
Thanks Perrin. I will take a look at FastCGI. Its just that mod_perl provides all the http infrastructure so neatly, its very tempting to consider emulating Apache and reuse mod_perl. But I see your point. regards, Deven Perrin Harkins-3 wrote: On Tue, Aug 25, 2009 at 3:00 PM, dbadhanidbadh...@yahoo.com wrote: This may sound far fetched, but has anyone tried porting mod_perl for web servers other than Apache. No, and it wouldn't really work. A generic approach to running persistent code already exists in the form of FastCGI. The rest of mod_perl is a perl interface to the Apache API, which makes it unsuitable for other web servers. Basically, I am looking for integrating some of mod_perl functionality in some high performance middleware, basically to provide a way to customized, scriptable request processing in the request processing engine. You could look at FastCGI, or embedding perl directly. - Perrin -- View this message in context: http://www.nabble.com/portability-of-mod_perl-for-other-web-servers-apps-tp25140259p25155493.html Sent from the mod_perl - General mailing list archive at Nabble.com.
PerlRun Subroutine redefine warnings
Hi,
I am running mod_perl/2.0.4 on Linux , I keep getting the subroutine
redefined warnings. Perlrun reloads the cgi on each request so why do
I keep getting these warnings ? Is there any other way to avoid this
other than no warnings qw/redefine/ in my scripts. Am I missing
something here ?.
Here is a minimal script I tested with
#!/usr/bin/perl
use strict;
use warnings;
print Content-type:text/html \n\n;
test();
test();
sub test {
print in test \n;
}
and here is my httpd.conf
PerlModule ModPerl::PerlRun
Location /cgi-bin
SetHandler perl-script
PerlHandler ModPerl::PerlRun
PerlSetVar ReloadAll Off
PerlResponseHandler +ModPerl::PerlRun
PerlOptions +ParseHeaders
PerlSendHeader On
Options +ExecCGI
/Location
PerlRequire /opt/nms/www/cgi-bin/startup.pl
# I modify @INC in startup.pl and do not load any modules
Error in the error_log
Subroutine test redefined at /opt/nms/www/cgi-bin/test1.pl line 22.
Subroutine test redefined at /opt/nms/www/cgi-bin/test1.pl line 10.
Thanks,
Kiran
Re: PerlRun Subroutine redefine warnings
This error occurs when you have two subroutines with the same name.
Mike O'Krongli
President and CTO
Acorg Inc
519 432-1185
- Original Message -
From: Kiran Kumar mkira...@gmail.com
To: modperl@perl.apache.org
Sent: Wednesday, August 26, 2009 8:07 PM
Subject: PerlRun Subroutine redefine warnings
Hi,
I am running mod_perl/2.0.4 on Linux , I keep getting the subroutine
redefined warnings. Perlrun reloads the cgi on each request so why do
I keep getting these warnings ? Is there any other way to avoid this
other than no warnings qw/redefine/ in my scripts. Am I missing
something here ?.
Here is a minimal script I tested with
#!/usr/bin/perl
use strict;
use warnings;
print Content-type:text/html \n\n;
test();
test();
sub test {
print in test \n;
}
and here is my httpd.conf
PerlModule ModPerl::PerlRun
Location /cgi-bin
SetHandler perl-script
PerlHandler ModPerl::PerlRun
PerlSetVar ReloadAll Off
PerlResponseHandler +ModPerl::PerlRun
PerlOptions +ParseHeaders
PerlSendHeader On
Options +ExecCGI
/Location
PerlRequire /opt/nms/www/cgi-bin/startup.pl
# I modify @INC in startup.pl and do not load any modules
Error in the error_log
Subroutine test redefined at /opt/nms/www/cgi-bin/test1.pl line 22.
Subroutine test redefined at /opt/nms/www/cgi-bin/test1.pl line 10.
Thanks,
Kiran
Re: RFC: Apache2::CloseKeepAlive
On Aug 26, 2009, at 11:44 AM, Michael Peters wrote: cr...@animalhead.com wrote: The installation process needs to know at least: 1. where the accompanying DB-building script should go Module::Build knows where to put bin/ or script/ files and it does so according to how Perl and CPAN are configured. I assume EU::MM does too. So if I put the script in a subdirectory bin of Apache2- CloseKeepAlive-n.nn/, the install step should automatically put it somewhere in the path. This is good information, thank you! I have no idea what EU::MM is. Candy from Europe? 2. where the DB that the app builds should go That's probably something your application should allow to be specified, either a command line option to the script or an option to the module, or both. My plan was to run the script the first time under Build.PL, to verify that it succeeds and because without the DB there can be no testing. In which case, asking the user where to put the DB, and propagating the answer to the script source and the module source, seems to me like the easiest course for everyone. This kind of prompt is not evil, in that the automated testers can be handled by giving the query a default, maybe '/tmp'. How can such necessary things be determined, other than by asking the user? If it's a run time option (and can be changed or multiple programs can use this and thus want different values) don't ask for it at install time. It's not a run time option. The subject is a mod_perl2 script, that can only be used within the Apache2 server. I can't conceive why the DB name would ever change, and multiple programs won't use the module. I was just going to add a note before or after these two queries, that if they have a mod_perl2 library and want the module to go there, they should do this. Putting extra docs in your module is ok, but I personally wouldn't repeat the docs that are already out there. I personally regard docs already out there as things that should be restated in here whenever the user can profit from them. As I just wrote to Perrin off-list, since only a tiny fraction of CPAN downloads are mod_perl2 modules, no one can configure CPAN for a mod_perl2 library. All perl libraries should go in the same place IMO. Whether it's Apache specific, or GTK or something else. I don't want to have to mess with @INC just because someone put something someplace non- standard. It seems that you and Perrin are in the same boat, which has One Perl Library For All painted on it. I am in a different boat with the authors of various mod_perl books. I set up my site under the guidance of Practical mod_perl p. 34: Now you have to select a directory where all the mod_perl scripts and modules will be placed. We usually create a directory called modperl under our home directory for this purpose (e.g., /home/stas/modperl), but it is also common to create a directory called perl under your Apache server root, such as /usr/local/apache/perl. (It's /usr/local/apache2/plib on my site.) This theme is echoed on p. 58 of the mod_perl2 User's Guide: You often need to adjust the contents of @INC before the server starts, usually to give the server additional places to look for your mod_perl code. There are several ways to do this: • startup.pl In the startup file you can use the lib pragma like so: use lib qw(/home/httpd/projectl/lib/tmp/lib); use lib qw(/home/httpd/project2/lib); • httpd.conf In httpd.conf you can use the PerlSwitches directive to pass arguments to Perl as you do from the command line. PerlSwitches -I/home/httpd/projectl/lib -I/tmp/lib PerlSwitches -I/home/httpd/project2/lib And on p. 61 of the mod_perl Developer's Cookbook: For a similar option, configure your startup.pl as use lib qw(/home/www/lib); ... By default, mod_perl adds two directories to @INC: ServerRoot/ and ServerRoot/lib/perl/, where ServerRoot is the value of the ServerRoot directive. ... If you are using a startup.pl to preload your modules, you will probably need to take advantage of the use lib syntax. Given all this, I blithely talk about the mod_perl library as if it's a standard part of every mod_perl site, and you and Perrin regard me as someone from another planet. Which is actually true, but that's another story. So now if Makefile.PL doesn't find 'mm' in /usr/local/lib, it prompts the user to enter the path to 'mm', which is then passed to Devel::CheckLib. The query is accompanied by a note showing the URL from which 'mm' can be downloaded. Personally, I'd just bomb out if you can't find the lib (and Devel::CheckLib is good for that). Give the user a message that you can't find the library and then exit. I doubt that someone who has a library that's not in the system libs will know where it is, and if they do they can just as easily set LD_LIBRARY_PATH themselves. This happens to me fairly regularly when
Re: mod_perl on win32
On Wed, Aug 26, 2009 at 12:40 PM, Michiel Beijenmichiel.bei...@otrs.com wrote: Foo JH wrote: I'd suggest to get your mp2 up with the following stack: Apache22 Windows binary ActivePerl binary precompiled mod_perl2 + libapreq2 from the repo That would be the easy way, right ;-) The thing is, my project uses a software bundle which includes Apache and Strawberry for the Windows installer. Due to licensing requirements you could not bundle ActiveState in an open source product; therefore the Strawberry requirement. It is just too bad that ApachePerl is not alive anymore. Any tips for compiling mod_perl with Strawberry are still welcome! Regards, Michiel Recent Strawberry distributions contain the ppm utility, which can be used to install ppm packages. I'm not sure if the relevant ppm package: http://perl.apache.org/docs/2.0/os/win32/install.html#PPM_Packages for mod_perl and libapreq2 would be compatible, but it would probably be worth trying. -- best regards, Randy
