Hello everybody,
I stumbled about a curious problem: Including <Python.h> changes the size of fpos_t.
m01% cat fpos_python.cc #ifdef HAVE_PYTHON_H #include <Python.h> #endif /* HAVE_PYTHON_H */ #include <stdio.h> int main(int argc, char** argv) { printf("sizeof(fpos_t) = %d\n",sizeof(fpos_t)); } m01% g++ -DHAVE_PYTHON_H -I/usr/include/python2.5 fpos_python.cc -lpython2.5 && ./a.out sizeof(fpos_t) = 16 m01% g++ -I/usr/include/python2.5 fpos_python.cc -lpython2.5 && ./a.out sizeof(fpos_t) = 12
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?
Thanks.
Regards, Dorian K.
"50 erste Dates" mit Adam Sandler u. Drew Barrymore kostenlos anschauen! Exklusiv für alle WEB.DE Nutzer. http://www.blockbuster.web.de
Dorian Krause doriankrause@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'".
On Thu, Oct 9, 2008 at 2:25 AM, Dorian Krause doriankrause@web.de wrote:
Hello everybody,
I stumbled about a curious problem: Including <Python.h> changes the size of fpos_t.
m01% cat fpos_python.cc #ifdef HAVE_PYTHON_H #include <Python.h> #endif /* HAVE_PYTHON_H */ #include <stdio.h> int main(int argc, char** argv) { printf("sizeof(fpos_t) = %d\n",sizeof(fpos_t)); } m01% g++ -DHAVE_PYTHON_H -I/usr/include/python2.5 fpos_python.cc -lpython2.5 && ./a.out sizeof(fpos_t) = 16 m01% g++ -I/usr/include/python2.5 fpos_python.cc -lpython2.5 && ./a.out sizeof(fpos_t) = 12
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?
Definitely a bug, but the question is why it happens. I don't see any python headers redefining it. It may be a bug in the system headers that python is just provoking.
gcc's -save-temps may provide some diagnostics. Also, try moving #include <stdio.h> above Python.h. I can't think of anything else at the moment.
-
Adam Olsen -
Dorian Krause -
Hrvoje Niksic