Debian Sid (httpd and python2.3 are stock debian):
$ /usr/bin/apxs2 -q CPPFLAGS
$ grep _FILE_OFFSET_BITS /usr/include/python2.3/pyconfig.h
#define _FILE_OFFSET_BITS 64
Jim
Gregory (Grisha) Trubetskoy wrote:
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