Apache Mod-Python - Cross-platform query: _FILE_OFFSET_BITS in python and httpd

This is Interesting: Free IT Magazines  
Home > Archive > Apache Mod-Python > March 2006 > Cross-platform query: _FILE_OFFSET_BITS in python and httpd





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author Cross-platform query: _FILE_OFFSET_BITS in python and httpd
Gregory (Grisha) Trubetskoy

2006-03-14, 5:46 pm


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

Jim Gallacher

2006-03-14, 5:46 pm

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
>



Graham Dumpleton

2006-03-14, 5:46 pm


On 15/03/2006, at 8:45 AM, 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


Apache 2.0.55/Python 2.3/Mac OS X 10.3.9

~ [507]$ /usr/local/apache-2.0/bin/apxs -q CPPFLAGS
~ [508]$ grep _FILE_OFFSET_BITS
/System/Library/Frameworks/Python.framework/Versions/Current/include/
python2.3/pyconfig.h
/* #undef _FILE_OFFSET_BITS */



Justin Erenkrantz

2006-03-14, 5:46 pm

On 3/14/06, Gregory (Grisha) Trubetskoy <grisha@ispol.com> wrote:
> 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 inod=

e
> (ino_t) is 32 bits and in Python it is 64 bits (this is what
> _FILE_OFFSET_BITS 64 does).


APR 1.0+ has LFS turned on by default. This means that httpd 2.0.xx
will have 32-bit files by default, but that LFS should be activated
for 2.1 and beyond.

The mod_perl guys have some tricks to get around this conflict as they
run into this same mismatch as well. -- justin

Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com