I was able to compile mod_wsgi for Python 2.5.4. It is now loaded into apache modules. I confirmed it by command
httpd.exe -M
.
.
wsgi_module(shared)
php5_module(shared)
But I am unable to run a test file(hello.wsgi), it is located in folder c:/apache/htdocs/wsgi : so the path of file becomes c:/apache/htdocs/wsgi/hello.wsgi
My hello.wsgi file contains:
def application(environ, start_response):
status = '200 OK'
output = 'Hello World!'
response_headers = [('Content-type', 'text/plain'),
('Content-Length', str(len(output)))]
start_response(status, response_headers)
return [output]
I added the following lines to httpd.conf:
LoadModule wsgi_module modules/mod_wsgi.so
<IfModule wsgi_module>
WSGIScriptAlias /wsgi/ "c:/apache/htdocs/wsgi/hello.wsgi"
<Directory "c:/apache/htdocs/wsgi">
Order deny,allow
allow from All
</Directory>
</IfModule>
And my Apache Error Log is :
[Sat Nov 19 15:29:32 2011] [warn] pid file C:/apache/logs/httpd.pid overwritten -- Unclean shutdown of previous Apache run?
[Sat Nov 19 15:29:32 2011] [warn] mod_wsgi: Compiled for Python/2.5.
[Sat Nov 19 15:29:32 2011] [warn] mod_wsgi: Runtime using Python/2.5.4.
[Sat Nov 19 15:29:33 2011] [notice] Apache/2.2.21 (Win32) mod_wsgi/3.3 Python/2.5.4 PHP/5.3.8 configured -- resuming normal operations
[Sat Nov 19 15:29:33 2011] [notice] Server built: Sep 9 2011 10:26:10
[Sat Nov 19 15:29:33 2011] [notice] Parent: Created child process 2296
[Sat Nov 19 15:29:33 2011] [warn] mod_wsgi: Compiled for Python/2.5.
[Sat Nov 19 15:29:33 2011] [warn] mod_wsgi: Runtime using Python/2.5.4.
[Sat Nov 19 15:29:33 2011] [notice] Child 2296: Child process is running
[Sat Nov 19 15:29:33 2011] [notice] Child 2296: Acquired the start mutex.
[Sat Nov 19 15:29:33 2011] [notice] Child 2296: Starting 64 worker threads.
[Sat Nov 19 15:29:33 2011] [notice] Child 2296: Starting thread to listen on port 80.
[Sat Nov 19 15:30:21 2011] [error] [client 127.0.0.1] File does not exist: C:/apache/htdocs/wsgi
Update
I removed the trailing slash from alias, i have moved my wsgi folder from htdocs to apache & created a vhost file:
<VirtualHost 127.0.0.1:80>
<Directory "C:/apache/wsgi">
Options FollowSymLinks Indexes
AllowOverride All
Order deny,allow
allow from All
</Directory>
ServerName 127.0.0.1
ServerAlias 127.0.0.1
WSGIScriptAlias /wsgi "C:/apache/wsgi/hello.wsgi"
DocumentRoot "C:/apache/wsgi"
ErrorLog "C:/apache/logs/127.0.0.1.err"
CustomLog "C:/apache/logs/127.0.0.1.log" combined
</VirtualHost>
But now my Apache is giving some windows error like:
Faulting application name: httpd.exe, version: 2.2.21.0, time stamp: 0x4e6a3015
Faulting module name: ntdll.dll, version: 6.1.7601.17514, time stamp: 0x4ce7ba58
Exception code: 0xc0000005
Fault offset: 0x00038da9
Faulting process id: 0xc4c
Faulting application start time: 0x01cca6c0f9ccd446
Faulting application path: C:\apache\bin\httpd.exe
Faulting module path: C:\Windows\SysWOW64\ntdll.dll
Report Id: 3ba0b9e0-12b4-11e1-b285-005056c00008
Need Some Help.
Thanks.
This sounds like the error that I had when the Visual C++ 2008 Redistributable (msvcr90.dll) was not installed on the system. But first, please check (with Dependency Walker) that
httpd.exeandmod_wsgi.soare using exactly the samemsvcr90.dll:If they are using different DLL names (e.g.
msvcr90.dllandmsvcr100.dll) then you must recompile both with the same compiler (e.g. Visual Studio 2008).If they are using the same DLL name, but different versions or in different directories, then you might be having the same problem that I had, with BitNami DjangoStack.
Because
msvcr90.dllwas not installed system-wide inC:\Windows\WinSxS,httpdwas only able to run at all because there was an “xcopy deployment” of the side-by-side assembly in the same directory as httpd.exe:Microsoft.VC90.CRT.manifestmsvcr90.dllIf these files had not been present, it would have failed due to a missing dependency on
msvcr90.dll, or else with this error:(i.e. the DLL was found but without a manifest to make it valid).
Although
httpd.exeruns this way, it is not able to reliably load a DLL that also usesmsvcr90.dll:You can see more about this kind of problem on Python bug 4120, although this is not a clear, complete and definitive explanation of the problem, and I have not been able to find one yet.
The only reliable way I found to run this stack was to install the Visual C++ 2008 redistributable system-wide, which places a copy of
msvcr90.dllin a subdirectory ofC:\Windows\WinSxSalong with a manifest to make it work.This should (I think) cause Windows to completely ignore the
Microsoft.VC90.CRT.manifestandmsvcr90.dllfiles in the application and DLL directories. Both should use the same DLL inC:\Windows\WinSxS, and it should only be loaded into the process once.