ramkrishanbhatt / modwsgi

Automatically exported from code.google.com/p/modwsgi
0 stars 0 forks source link

When will mod_wsgi support Python 3.x? #256

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
I added mod_wsgi 3.3 with apache 2.2.9 on windows 7.

The apache can't be started when load module mod_wsgi, someone told I need 
mod_wsgi 4, where/when can I download it?

Original issue reported on code.google.com by toheq...@gmail.com on 13 Jan 2012 at 3:30

GoogleCodeExporter commented 8 years ago
Which exact version of Python are you wanting to use?

There are already binaries for Python 3.1.

Python 3.2+ will require mod_WSGI 4.0, but even then there appears to be some 
issue which is causing it not to build/work properly when people build it from 
current source code. I haven't had the time investigate.

The Python 3.1 binary for 32 bit Apache/Python is available from download site. 
There are no 64 bit binary there, but there is apparently a third party site 
where some one is providing 64 bit binary, I don't have link handy right now 
though.

Original comment by Graham.Dumpleton@gmail.com on 13 Jan 2012 at 9:30

GoogleCodeExporter commented 8 years ago
Thanks for your reply, Dumpleton.

I'm using Python 3.2, so I think I have to wait for the mod_wsgi 4.

Original comment by toheq...@gmail.com on 14 Jan 2012 at 12:10

GoogleCodeExporter commented 8 years ago
I built the latest hg mod_wsgi to get Python 3.2 support. I noticed a couple 
issues:

- First, Windows-specific makefile (win32-ap22py31.mk) issues: even after 
changing the paths to fit my setup, Apache complained that the wsgi_module 
export was missing from the module. I noticed that nmake was warning that $< 
was unset, and moved mod_wsgi.c into SRCCFILES and deleted the reference to $<. 
This fixed the first issue of mod_wsgi.c being excluded from the build.

- Second, there's an #if defined(MOD_WSGI_WITH_DAEMONS) in mod_wsgi.c at 
"Apache 2.X and UNIX specific code for creation and management" \ "of distinct 
daemon processes." that encompasses too much: it goes to the end of the 
wsgi_module structure. That #endif should be moved to the end of the "daemon" 
section, i.e., before "Apache 2.X module initialisation functions.". Symptom: 
Apache claims that the signature value is 00000000. Dumping the file with 
dumpbin shows that the wsgi_module symbol doesn't have any bytes in the file 
(presumably it gets allocated as uninitialized data, or randomly and happened 
to hit an area of zeroed memory). With the #endif move, Apache accepts it and 
it works fine, except that I had to modify the example's output to be bytes 
(b'') not a string.

- Environment: Windows 7, Apache 2.2.21, Python 3.2, x64.

Original comment by yout...@czth.net on 17 Jan 2012 at 5:38

GoogleCodeExporter commented 8 years ago
Oh, there was also a problem with wsgi_apr_unix_file_cleanup in wsgi_apache.c 
being undefined since it's behind an APR check. I just commented out the #if 
check that excluded it; probably not a long term solution, but it make it work.

Original comment by yout...@czth.net on 17 Jan 2012 at 7:01

GoogleCodeExporter commented 8 years ago
Believed to all be addressed in mod_wsgi trunk for 4.0 now, although 
compilation not confirmed on Windows.

Original comment by Graham.Dumpleton@gmail.com on 19 Mar 2012 at 10:18

GoogleCodeExporter commented 8 years ago

Original comment by Graham.Dumpleton@gmail.com on 28 Mar 2013 at 6:40

GoogleCodeExporter commented 8 years ago
Changes were back ported for 3.4.

Original comment by Graham.Dumpleton@gmail.com on 28 Mar 2013 at 6:40