You are viewing a plain text version of this content. The canonical link for it is here.

Posted to modperl@perl.apache.org by "Desilets, Alain" <Al...@nrc-cnrc.gc.ca> on 2011/11/29 15:00:20 UTC

Installing mod_perl on Windows 7

Hi folks,

This is my first post on this list.

I am trying to install mod_perl on Windows 7, and am running into some problems.

Here's what I did.

First, I ran the following commands to get the mod_perl package and install it:

----------------
ppm rep add http://cpan.uwinnipeg.ca/PPMPackages/12xx
ppm install mod_perl
----------------

Then I added the following lines at the start of my httpd.conf file:

----------------
LoadFile "C:/Perl/bin/perl512.dll"
LoadModule perl_module modules/mod_perl.so
----------------

But since then, Apache won't restart,  unless I comment out those two lines. To diagnose the problem, I ran the command:

----------------
httpd.exe -t -c httpd.conf
----------------

And it gives me the following error message:

----------------
httpd: Syntax error on line 29 of C:/wamp/bin/apache/Apache2.2.17/conf/httpd.conf: Cannot load C:/Perl/bin/perl512.dll into server: %1 is not a valid Win32 application.
----------------

The file C:/Perl/bin/perl512.dll does exist.

I am wondering if the problem is not due to a difference between 32 and 64 bits applications. I ran a small perl script which looks at the DOS headers of executables, to find the architecture that the executable was compiled for, and here's what it tells me:

httpd.exe: AMD64
perl512.dll: i386
mod_perl.so: i386

I would think that a 64 Apache is able to load a 32 bit DLL, no?

Does anyone have some ideas or suggestions?

Thx.

Alain Désilets



Alain Désilets
Agent de recherche | Research Officer
Institut de technologie de l'information | Institute for Information Technology Conseil national de recherches du Canada | National Research Council of Canada

Re: Installing mod_perl on Windows 7

Posted by gAzZaLi <ba...@bac2bac.com>.

Looks like you're all set and running mod_perl 2.

In mod_perl 2, $ENV{GATEWAY_INTERFACE} is not special. It was only 
special in mod_perl 1, in that it said CGI-Perl/1.1 under mod_perl 1 
rather than CGI/1.1.

To see if you're running under mod_perl 2, check $ENV{MOD_PERL}.
You see that it's set in your system from what you've cut and pasted so 
you are running under mod_perl 2!

Good luck!


On 11/29/2011 1:02 PM, Desilets, Alain wrote:
> Thx again for the help. I tried what you suggested (after reading gAzZaLi's answer), but it still doesn't seem to help.
>
> Here are the lines I have added to my httpd.conf file:
>
> ----------------
> LoadFile "C:/Perl/bin/perl512.dll"
> LoadModule perl_module modules/mod_perl.so
> ----------------
>
> And a bit further...
>
> ------------------
> Alias /perl/ "C:/wamp/www/perl/"
> <Location /perl/>
>        SetHandler perl-script
>        PerlResponseHandler ModPerl::Registry
>        PerlOptions +ParseHeaders
>        Options +ExecCGI
>        Order allow,deny
>        Allow from all
> </Location>
> ------------------
>
> I have a script C:/wamp/www/perl/printenv.pl, which prints the content of the %ENV hash. When I run it, I still get CGI/1.1 for the GATEWAY_INTERFACE key. See output at the end of this message.
>
> Note that I do get
>
> 	MOD_PERL:	mod_perl/2.0.4
>
> Which seems to indicate that mod_perl is indeed installed. But it doesn't seem to be actually invoked for running the script.
>
> Any additional advice?
>
> Thx.
>
> Alain
>
> === Output of http://localhost/perl/printenv.pl ===
>
> SCRIPT_NAME:	/perl/printenv.pl
> SERVER_NAME:	localhost
> SystemRoot:	C:\Windows
> SERVER_ADMIN:	admin@localhost
> HTTP_ACCEPT_ENCODING:	gzip, deflate
> HTTP_CONNECTION:	keep-alive
> REQUEST_METHOD:	GET
> HTTP_ACCEPT:	text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
> SCRIPT_FILENAME:	C:/wamp/www/perl/printenv.pl
> COMSPEC:	C:\Windows\system32\cmd.exe|
> SERVER_SOFTWARE:	Apache/2.2.21 (Win32) PHP/5.3.8 mod_perl/2.0.4 Perl/v5.12.3
> HTTP_ACCEPT_CHARSET:	ISO-8859-1,utf-8;q=0.7,*;q=0.7
> WINDIR:	C:\Windows
> QUERY_STRING:	
> REMOTE_PORT:	56619
> PATHEXT:	.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
> HTTP_USER_AGENT:	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0
> SERVER_PORT:	80
> SERVER_SIGNATURE:	
> HTTP_ACCEPT_LANGUAGE:	fr-ca,fr;q=0.8,en-us;q=0.5,en;q=0.3
> REMOTE_ADDR:	127.0.0.1
> SERVER_PROTOCOL:	HTTP/1.1
> PATH:	C:\Perl\site\bin;C:\Perl\bin;C:\Perl64\site\bin;C:\Perl64\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\Common Files\Roxio Shared\DLLShared\;C:\Program Files (x86)\Common Files\Roxio Shared\10.0\DLLShared\;C:\cygwin\bin;C:\Program Files (x86)\QuickTime\QTSystem\; C:\Users\Desiletsa\android-sdks\tools;
> MOD_PERL_API_VERSION:	2
> REQUEST_URI:	/perl/printenv.pl
> GATEWAY_INTERFACE:	CGI/1.1
> SERVER_ADDR:	127.0.0.1
> DOCUMENT_ROOT:	C:/wamp/www
> HTTP_HOST:	localhost
> MOD_PERL:	mod_perl/2.0.4
>
>
>
> -----Original Message-----
> From: André Warnier [mailto:aw@ice-sa.com]
> Sent: Tuesday, November 29, 2011 3:25 PM
> To: mod_perl list
> Subject: Re: Installing mod_perl on Windows 7
>
> Desilets, Alain wrote:
>> OK, so I uninstalled Apache 64 bits, and installed Apache 32 bits instead.
>>
>> Now, Apache starts correctly with the following two lines in httpd.conf
>>
>> ----------------
>> LoadFile "C:/Perl/bin/perl512.dll"
>> LoadModule perl_module modules/mod_perl.so
>> ----------------
>>
>> Only problem is that my scripts still seem to run under the conventional CGI interface, instead of mod_perl. For example, if I run this script:
>>
>> ----------------
>> #!C:/Perl/bin/perl
>>
>> print "Content-type: text/plain\r\n\r\n";
>>
>> print "Server's gateway interface:\t$ENV{GATEWAY_INTERFACE}\n\n";
>>
>> print "Other values of the server environment:\n";
>> foreach my $a_key ( keys %ENV ) {
>>      print "$a_key:\t$ENV{$a_key}\n";
>> }
>> ------------------
>>
>> I get "Server's gateway interface:	CGI/1.1", and according to this page:
>>
>> http://perl.apache.org/docs/1.0/guide/install.html#Testing_via_a_CGI_script
>>
>> this means I am NOT running mod_perl. If I WAS running mod_perl, I should be seeing something like 'CGI-Perl/1.1' instead.
>>
>> Note that I saw the following line in httpd.conf
>>
>> ---------------
>> LoadModule cgi_module modules/mod_cgi.so
>> ---------------
>>
>> I tried commenting it out, thinking that maybe this was overriding mod_perl. But when I do that, my scripts don't run as a perl script anymore. Instead, the source code of the scripts is displayed in the browser when I try to invoke it.
>>
>> I have looked through all the documentation I could find about installing mod_perl for windows, and I can't find any additional step beyond the ones I have taken so far.
>>
>> Any suggestions you have will be greatly appreciated.
>>
>
> If your cgi scripts are only Perl and shell scripts, then you need to add something to
> your<Location /cgi-bin>  section. Look here :
>
> http://perl.apache.org/docs/2.0/user/intro/start_fast.html#Registry_Scripts
>
> Basically, it means that you need to tell Apache that for the files in that directory, the
> Apache handler (the module which generates the responses to the requests) is mod_perl.
>
> (mod_perl is smart enough that when it sees a shell script, it will call the shell to run
> it, instead of itself).
>
> Make sure that you read the caveats of running scripts under mod_perl (persistence e.g.).
>
>
>> Thx.
>>
>> Alain Désilets
>>
>>
>> -----Original Message-----
>> From: André Warnier [mailto:aw@ice-sa.com]
>> Sent: Tuesday, November 29, 2011 10:48 AM
>> To: mod_perl list
>> Subject: Re: Installing mod_perl on Windows 7
>>
>> Desilets, Alain wrote:
>>> Hi folks,
>>>
>>> This is my first post on this list.
>>>
>>> I am trying to install mod_perl on Windows 7, and am running into some problems.
>>>
>>> Here's what I did.
>>>
>>> First, I ran the following commands to get the mod_perl package and install it:
>>>
>>> ----------------
>>> ppm rep add http://cpan.uwinnipeg.ca/PPMPackages/12xx
>>> ppm install mod_perl
>>> ----------------
>>>
>>> Then I added the following lines at the start of my httpd.conf file:
>>>
>>> ----------------
>>> LoadFile "C:/Perl/bin/perl512.dll"
>>> LoadModule perl_module modules/mod_perl.so
>>> ----------------
>>>
>>> But since then, Apache won't restart,  unless I comment out those two lines. To diagnose the problem, I ran the command:
>>>
>>> ----------------
>>> httpd.exe -t -c httpd.conf
>>> ----------------
>>>
>>> And it gives me the following error message:
>>>
>>> ----------------
>>> httpd: Syntax error on line 29 of C:/wamp/bin/apache/Apache2.2.17/conf/httpd.conf: Cannot load C:/Perl/bin/perl512.dll into server: %1 is not a valid Win32 application.
>>> ----------------
>>>
>>> The file C:/Perl/bin/perl512.dll does exist.
>>>
>>> I am wondering if the problem is not due to a difference between 32 and 64 bits applications. I ran a small perl script which looks at the DOS headers of executables, to find the architecture that the executable was compiled for, and here's what it tells me:
>>>
>>> httpd.exe: AMD64
>>> perl512.dll: i386
>>> mod_perl.so: i386
>>>
>>> I would think that a 64 Apache is able to load a 32 bit DLL, no?
>> No.
>>> Does anyone have some ideas or suggestions?
>>
>> a 64-bit Windows can run 32 and 64 applications.  But within an application, you cannot
>> mix and match.
>> So either get a 64-bit perl and mod_perl, or get a 32-bit Apache.
>> I would suggest a 32-bit Apache, as for a workstation, you are unlikely to need the extra
>> memory that 64-bit would allow you to use; and your 32-bit applications will use less
>> memory in vain.
>>
>>
>>
>
>
>

Re: Running multiple copies of same site in ModPerl

Posted by gAzZaLi <ba...@bac2bac.com>.

Hello,

What you're doing is not recommended as you run into namespace issues.

Perl caches files and modules that were loaded in %INC, so if you have 
files and modules with the same name, only one of them gets loaded. 
Possibly, as an exercise, if you switch the order of the ORIG and COPY 
lines in your startup.pl, you'll see the changes you've made in ORIG and 
not the changes in COPY.

I've made the assumption here that your site is more than just the one 
base.pm file and both base.pm packages use other packages with the same 
names.

Suppose your

ORIG::mods::base.pm has "use mods::somepackage"
and
COPY::mods::base.pm has "use mods::somepackage",

with the startup.pl file, Perl will load only the 
.../perl/COPY/mods/somepackage.pm file.

If however your site is just the base.pm file, and the package 
declaration is as you've written, my answer is off.

Good luck.

g.

On 11/29/2011 7:29 PM, Nishikant Kapoor wrote:
> Hello List,
>
> I have been running a ModPerl site fine with following configuration.
> The problem started when I made a complete copy of the original site and
> tried to run the two in the same environment. For some reason, calling
> up the ORIG site (http://127.0.0.1/ORIG/) now calls the COPY site at
> http://127.0.0.1/COPY/. None of the changes made in ORIG::MODS::base.pm
> are getting picked up even after restarting the apache server. However,
> changes to COPY::MODS::base.pm are showing up fine.
>
> Would appreciate any help. Here is what I have in the config:
>
> /etc/httpd/conf/httpd.conf:
> ---------------------------
> PerlRequire /var/www/perl/startup.pl
> <Location /ORIG>
> SetHandler perl-script
> PerlResponseHandler ORIG::MODS::base
> </Location>
>
> <Location /COPY>
> SetHandler perl-script
> PerlResponseHandler COPY::MODS::base
> </Location>
>
> /var/www/perl/startup.pl:
> -------------------------
> use lib qw(/var/www/perl);
> use lib qw(/var/www/perl/ORIG);
> use lib qw(/var/www/perl/COPY);
> 1;
>
> Apache/2.2.14 (Mandriva Linux/PREFORK-1mdv2010.0)
> apache-mod_perl-2.0.4-11mdv2010.0
> This is perl, v5.10.1 (*) built for x86_64-linux-thread-multi
>
> Thanks,
> Nishi
>
>
>

Re: Running multiple copies of same site in ModPerl

Posted by Rolf Schaufelberger <rs...@plusw.de>.

Am 30.11.2011 um 15:02 schrieb Michael Peters:

> On 11/29/2011 10:29 PM, Nishikant Kapoor wrote:
> 
>> I have been running a ModPerl site fine with following configuration.
>> The problem started when I made a complete copy of the original site and
>> tried to run the two in the same environment. For some reason, calling
>> up the ORIG site (http://127.0.0.1/ORIG/) now calls the COPY site at
>> http://127.0.0.1/COPY/. None of the changes made in ORIG::MODS::base.pm
>> are getting picked up even after restarting the apache server. However,
>> changes to COPY::MODS::base.pm are showing up fine.
> 
> The problem is that mod_perl uses the same Perl interpreter for everything (by default) and that interpreter is persistent. I'm guessing that your "package" declaration in ORIG::MODS::base.pm and COPY::MODS::base.pm are the same. Perl won't load 2 packages of the same name. The usual solutions are:
> 
> 1) rename your modules so that they don't have the same package names.
> 
> 2) run multiple separate apaches on the same physical server (not as hard as it seems to most people and pretty easy to do if you're running a proxy in front. And you really should be running a proxy in front).
> 
> 3) Try to have multiple Perl interpreters using a different Apache MPM. I haven't seen anyone give a definitive guide to how to do this (although I could have missed something) and results seem to be mixed.
> 
> I prefer #2 and use it constantly. It also makes it really easy to have separate dev environments each using their own code.
> 

You could do that too with the "+parent" option, see mod_perl docs. So you don't need another apache instance (but you need a lot of RAM ).
This creates an own interpreter. But I'm not sure if  it can be applied  on a <Location> level or at least on <VirtualHost>


Rolf Schaufelberger

Re: Running multiple copies of same site in ModPerl

Posted by gAzZaLi <ba...@bac2bac.com>.

My point about switching the lines in startup.pl was to give you a 
better understanding of what was going on. It was not intended as a fix.

Looks like you've got your base.pm package declaration right. But for 
your sites to work as intended, you've got to do that for all the 
modules in /ORIG/mods and /COPY/mods, not just the response handler. And 
then you have to change all the code that once refered to 
"mods::something" to "ORIG::mods::something" and same for COPY.
But please do NOT do this as it's a bad idea and leads to premature aging.

If you're interested further in the namespace issue, check this out from 
the Practial mod_perl book:
http://modperlbook.org/html/6-3-Namespace-Issues.html

As for a good solution, which I forgot to mention but others have, go 
with #2 -- setting up separate instances of Apache on the same physical 
server. The Practical mod_perl book has information on multiple server 
setups too and good points to consider when running separate dev, 
staging and production servers.


On 11/30/2011 10:15 AM, Nishikant Kapoor wrote:
> Michael Peters wrote:
>> On 11/29/2011 10:29 PM, Nishikant Kapoor wrote:
>>
>>> I have been running a ModPerl site fine with following configuration.
>>> The problem started when I made a complete copy of the original site and
>>> tried to run the two in the same environment. For some reason, calling
>>> up the ORIG site (http://127.0.0.1/ORIG/) now calls the COPY site at
>>> http://127.0.0.1/COPY/. None of the changes made in ORIG::MODS::base.pm
>>> are getting picked up even after restarting the apache server. However,
>>> changes to COPY::MODS::base.pm are showing up fine.
>>
>> The problem is that mod_perl uses the same Perl interpreter for
>> everything (by default) and that interpreter is persistent. I'm
>> guessing that your "package" declaration in ORIG::MODS::base.pm and
>> COPY::MODS::base.pm are the same. Perl won't load 2 packages of the
>> same name. The usual solutions are:
> I thought about that too, and so I did change the "package" declaration
> in ORIG::MODS::base.pm and COPY::MODS::base.pm but calling up
> http://127.0.0.1/ORIG/ still calls http://127.0.0.1/COPY/. Here is what
> each base.pm has:
>
> /var/www/perl/COPY/MODS/base.pm:
> package COPY::MODS::base;
>
> /var/www/perl/ORIG/MODS/base.pm:
> package ORIG::MODS::base;
>
> And, as gAzZaLi suggested, I also tried switching the order of the ORIG
> and COPY lines in startup.pl, and I could see the changes made in ORIG
> but not the changes in COPY. So, COPY indeed is overriding ORIG.
>
> As for the #2 mentioned below, are there any pointers that you could
> refer to?
>
> Thanks,
> Nishi
>>
>> 1) rename your modules so that they don't have the same package names.
>>
>> 2) run multiple separate apaches on the same physical server (not as
>> hard as it seems to most people and pretty easy to do if you're
>> running a proxy in front. And you really should be running a proxy in
>> front).
>>
>> 3) Try to have multiple Perl interpreters using a different Apache
>> MPM. I haven't seen anyone give a definitive guide to how to do this
>> (although I could have missed something) and results seem to be mixed.
>>
>> I prefer #2 and use it constantly. It also makes it really easy to
>> have separate dev environments each using their own code.
>>
>
>
>

Re: Running multiple copies of same site in ModPerl

Posted by Nishikant Kapoor <nk...@webrachna.com>.

Michael Peters wrote:
> On 11/29/2011 10:29 PM, Nishikant Kapoor wrote:
>
>> I have been running a ModPerl site fine with following configuration.
>> The problem started when I made a complete copy of the original site and
>> tried to run the two in the same environment. For some reason, calling
>> up the ORIG site (http://127.0.0.1/ORIG/) now calls the COPY site at
>> http://127.0.0.1/COPY/. None of the changes made in ORIG::MODS::base.pm
>> are getting picked up even after restarting the apache server. However,
>> changes to COPY::MODS::base.pm are showing up fine.
>
> The problem is that mod_perl uses the same Perl interpreter for 
> everything (by default) and that interpreter is persistent. I'm 
> guessing that your "package" declaration in ORIG::MODS::base.pm and 
> COPY::MODS::base.pm are the same. Perl won't load 2 packages of the 
> same name. The usual solutions are:
I thought about that too, and so I did change the "package" declaration 
in ORIG::MODS::base.pm and COPY::MODS::base.pm but calling up 
http://127.0.0.1/ORIG/ still calls http://127.0.0.1/COPY/. Here is what 
each base.pm has:

/var/www/perl/COPY/MODS/base.pm:
package COPY::MODS::base;

/var/www/perl/ORIG/MODS/base.pm:
package ORIG::MODS::base;

And, as gAzZaLi suggested, I also tried switching the order of the ORIG 
and COPY lines in startup.pl, and I could see the changes made in ORIG 
but not the changes in COPY. So, COPY indeed is overriding ORIG.

As for the #2 mentioned below, are there any pointers that you could 
refer to?

Thanks,
Nishi
>
> 1) rename your modules so that they don't have the same package names.
>
> 2) run multiple separate apaches on the same physical server (not as 
> hard as it seems to most people and pretty easy to do if you're 
> running a proxy in front. And you really should be running a proxy in 
> front).
>
> 3) Try to have multiple Perl interpreters using a different Apache 
> MPM. I haven't seen anyone give a definitive guide to how to do this 
> (although I could have missed something) and results seem to be mixed.
>
> I prefer #2 and use it constantly. It also makes it really easy to 
> have separate dev environments each using their own code.
>

Re: Running multiple copies of same site in ModPerl

Posted by Michael Peters <mp...@plusthree.com>.

On 11/29/2011 10:29 PM, Nishikant Kapoor wrote:

> I have been running a ModPerl site fine with following configuration.
> The problem started when I made a complete copy of the original site and
> tried to run the two in the same environment. For some reason, calling
> up the ORIG site (http://127.0.0.1/ORIG/) now calls the COPY site at
> http://127.0.0.1/COPY/. None of the changes made in ORIG::MODS::base.pm
> are getting picked up even after restarting the apache server. However,
> changes to COPY::MODS::base.pm are showing up fine.

The problem is that mod_perl uses the same Perl interpreter for 
everything (by default) and that interpreter is persistent. I'm guessing 
that your "package" declaration in ORIG::MODS::base.pm and 
COPY::MODS::base.pm are the same. Perl won't load 2 packages of the same 
name. The usual solutions are:

1) rename your modules so that they don't have the same package names.

2) run multiple separate apaches on the same physical server (not as 
hard as it seems to most people and pretty easy to do if you're running 
a proxy in front. And you really should be running a proxy in front).

3) Try to have multiple Perl interpreters using a different Apache MPM. 
I haven't seen anyone give a definitive guide to how to do this 
(although I could have missed something) and results seem to be mixed.

I prefer #2 and use it constantly. It also makes it really easy to have 
separate dev environments each using their own code.

-- 
Michael Peters
Plus Three, LP