[capi-sig] python and fpos_t

Hrvoje Niksic hniksic at xemacs.org
Thu Oct 9 10:50:06 CEST 2008


Dorian Krause <doriankrause at web.de> writes:

> I stumbled about a curious problem: Including <Python.h> changes the
> size of fpos_t.
[...]
> This breaks my code if I do not include <Python.h> in ALL of my
> compilation modules (which is not pratical in my opinion).
>
> Is this a known problem? I personally would call this definitely a
> bug. What is the rational behind changing fpos_t?

This is a result of Python.h requesting "large file support" from the
libc, by something like "#define _FILE_OFFSET_BITS 64".  So it's not
the case that Python defines its own version fpos_t, it tells libc to
consistently use 64-bit quantities for file offset, which changes
off_t, fpos_t, and probably other file-related types.  Without this
Python itself wouldn't support files larger than 2G.

You can compile your other modules with "#define _FILE_OFFSET_BITS 64"
and you'll be compatible with Python without including all of
Python.h.  These macros are described in some detail in the glibc
manual, "info libc 'Feature Test Macros'".


More information about the capi-sig mailing list