quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gregory (Grisha) Trubetskoy" <gri...@ispol.com>
Subject Cross-platform query: _FILE_OFFSET_BITS in python and httpd
Date Tue, 14 Mar 2006 21:45:44 GMT

Could folks with access to different OS's try the following:

Compare output of "apxs -q CPPFLAGS" with the value of _FILE_OFFSET_BITS 
in pyconfig.h.

For example, on my Fedora Core 4 i386 system (stock httpd and python):

$ /usr/sbin/apxs -q CPPFLAGS
-DSSL_EXPERIMENTAL_ENGINE

[note - no mention of _FILE_OFFSET_BITS above]


$ grep _FILE_OFFSET_BITS /usr/include/python2.4/pyconfig.h
#define _FILE_OFFSET_BITS 64


In case you're wondering, this is in relation to 
https://issues.apache.org/jira/browse/MODPYTHON-138
and to some degree https://issues.apache.org/jira/browse/MODPYTHON-20 and 
probably a few other "unexplained" issues.

What the output on Fedora Core 4 means is that essentially Python and 
APR/httpd are compiled in an incomatible way - in APR the size of an inode 
(ino_t) is 32 bits and in Python it is 64 bits (this is what 
_FILE_OFFSET_BITS 64 does).

This issue goes unnoticed when Python.h is included after http.h, but 
becomes very obvious if you put Python.h before http.h - httpd will 
segfault on the first request because the request_rec (which includes 
finfo, which includes ino_t inode) becomes incompatible between httpd and 
mod_python and anything past finfo in request_rec structure is junk (off 
by 4 bytes).

I wanted to see how widespread this problem is. I think the right solution 
is for configure to catch this (exactly how to best detect this I'm not 
yet sure) and stop cold.

Thanks,

Grisha

Mime
View raw message