Home / Documentation / General / OS-specific Info / Win32 / | ||||
Frequently asked questions for mod_perl on Win32 | ||||
|
||
apxs
utility.
Apache::Log
on Win32 so slow?
If you don't find a solution to your problem here, make sure to check the other troubleshooting documents according to the used mod_perl version as explained in the following sections.
If you have troubles with mod_perl 1.0, please refer to the following documents:
If the solution is still not found, see the guide to getting help with mod_perl 1.0.
If the solution is still not found, see the guide to getting help with mod_perl 2.0.
Yes, Perl is required. You can obtain a Win32 Perl binary from http://www.activestate.com/. See also the all-in-one binary packages for both mod_perl 1.0 and mod_perl 2.0 which include Perl, Apache, and mod_perl.
PPM packages for both mod_perl 1.0, for ActivePerl 6xx builds, and mod_perl 2.0, for ActivePerl 8xx builds, are available.
mod_perl 1.0, for use with Apache 1.0, is stable and well tested, while mod_perl 2.0, for use with Apache 2.0, is in a development stage. Normally, therefore, one would recommend mod_perl 2.0 only in a testing and development environment. However, on Win32 mod_perl 1.0 is subject to some serious threading limitations which are overcome with mod_perl 2.0; this, coupled with the improved performance of Apache 2.0 on Win32, may make mod_perl 2.0 a better choice.
This can be due to a number of reasons.
Verify that mod_perl.so was compiled against the same Perl and Apache versions that you are using. If you are using Apache/2.x, note that modules compiled under Apache/2.0 will not work under Apache/2.2, and vice-versa.
Check that the directory containing perl.exe
is in your PATH environment variable.
Try inserting a directive
LoadFile "C:/Path/to/your/Perl/bin/perlxx.dll"
before the
LoadModule perl_module modules/mod_perl.so
directive, where perlxx.dll is the Perl dll in your Perl bin directory.
Try a reboot.
This differs according to the flavour of Win32 you are using. Search for set PATH environment within the Windows Help utility under the Start menu for instructions.
You can test this by using a script which prints out the environment variables; note that for mod_perl 2.0 a slightly different configuration is required.
This means that the first line of your script (the shebang line),
#!/Path/to/Your/Perl/bin/Perl.exe
is not pointing to the location of your Perl binary. Shebang lines are common in a Unix environment, where they are used to indicate with which program a script is to be run by, but are not normally used as such on Win32, except in this context within Apache.
See the discussion of configuring Apache::Registry; for mod_perl 2.0, a different configuration is required.
If the extension of the file being called is pl
, or some
other common extension, and if the problem happens with a
browser on Windows, it may be that there is a file association
set up within Windows for that extension. Try changing the
extension of the file to something for which a file association
is normally not present, such as cgi
.
If this doesn't help, see the discussion about PerlSendHeader; note that for mod_perl 2.0, there is a different syntax.
Check the setting of PerlSendHeader; note that for mod_perl 2.0, there is a different syntax.
You are probably running into multithreading limitations of mod_perl 1.0; if this is a major problem, you should consider using mod_perl 2.0.
You should check the setting of PerlSendHeader; for mod_perl 2.0, there is a different syntax. If this setting is correct, and this occurs under mod_perl 2.0 and Perl-5.6.1, try upgrading to Perl-5.8.0.
If this is a custom module installed outside of the system Perl @INC directories, see perldoc lib. If this is a mod_perl module, and you are using mod_perl 2, try using the Apache2 module, as described in accessing mod_perl 2 modules.
This might be due to an incompatibility between the installed mod_perl files in the Perl tree and the mod_perl.so library within the Apache (or Apache2) modules directory. If you're installing mod_perl via ppm, first try removing mod_perl (or mod_perl-dev, if you're using the development version):
ppm> remove mod_perl
Next, remove (or move to another location) the mod_perl.so library under the Apache (or Apache2) modules directory:
C:\> del Apache2\modules\mod_perl.so
(assuming C:\Apache2 is your top-level Apache2 directory). You may have to stop Apache to be able to do this. Then install mod_perl via ppm:
ppm> install mod_perl
and ensure that the post-install script successfully fetches and installs mod_perl.so.
First off, if this is due to running some script from the command line, this might be normal behaviour, as many Apache modules require one to be in the Apache environment to work. If this does occur from within Apache, and is a problem with mod_perl 2.0, it may be that the right module hasn't been loaded - see the discussion of Command Line Lookups for a method to discover which module is needed.
For a mod_perl solution, check http://www.apache-asp.org/ for a discussion of the Apache::ASP module.
If these aren't available via ppm from the repositories for mod_perl 1.0 or mod_perl 2.0, you can build them using the CPAN.pm module.
The issue is not an Apache/mod_perl issue per se. Any service that
allows execution of external binaries that try to initialize and display
GUI components will have problems under OSs like Windows 2K+, Unix,
Linux and MacOS X.
This would have worked in Win 98 because apps all run in the same user
space (under the same user ID). Those resources happened to be, for the
most part, linked to almost everything else running on the system. Hence
when you ran a gui app from within Apache the system would display the
gui part of it on the screen. The OS saw no difference between the web
server running in the background and the user's desktop.
The best way to deal with this is to see if the application you are
trying to run has a /quiet switch or something that will keep it from
trying to draw any GUI components/dialog boxes to the screen. If you
wrote the application you are trying to execute then you should put a
hook into it that will allow that option (obviously adding the code to
bypass the gui code) and then execute it with the new option. The best
way to execute programs under Perl's system call is to write a console
application. If you would like to take output from that application then
you should write to STDOUT all text you want the perl application to see
as a return value from your qx
or `` (backticks) call.
Try putting the path to your database DLLs in your PATH environment variable. Also, make sure you are using the latest versions of DBI and your DBD::* driver.
For mod_perl 1.0, make sure you have installed the libapreq ppm package described for mod_perl 1.0 ppm packages; the libapreq package available in the ActiveState repository will not work under mod_perl. A libapreq2 package, suitable for use with mod_perl 2.0 / Apache 2.x, is available on http://www.cpan.org/, with Win32 ppm packages: libapreq2, for Apache/2.0, and libapreq2-2.2, for Apache/2.2, available as described for mod_perl 2.0 ppm packages.
apxs
utility.The utilities apxs
, apr-config
, and apu-config
have
not been fully ported yet to Win32 for Apache2. A development port
is available in the apxs_win32.tar.gz archive found under
http://apache.org/dist/perl/win32-bin/; installation
instructions are found in the accompanying README file.
One can also install these utilties by running the install_apxs
script under http://apache.org/dist/perl/win32-bin/. Note that
this port does not offer yet the full functionality of
the unix version - in particular, features enabling the utilities
to be used within the Apache2 sources are missing. Nevertheless,
they may be useful for building and installing 3rd-party C modules.
Apache::Log
on Win32 so slow?On Win32 Apache attempts to lock all writes to a file whenever
it's opened for append (which is the case with logging functions), as
Unix has this behavior built-in, while Win32 does not. Therefore
Apache::Log
functions could be slower than Perl's print()/warn().
Maintainer is the person(s) you should contact with updates, corrections and patches.
Randy Kobes <randy@theoryx5.uwinnipeg.ca>
Randy Kobes <randy@theoryx5.uwinnipeg.ca>
Only the major authors are listed above. For contributors see the Changes file.
|