Including Python.h changes sizeof(struct stat):

ralf@gandalf:~$ cat t.c
#ifdef USE_PYTHON
#include <Python.h>
#endif

#include <sys/stat.h>

main()
{
        printf ("sizeof=%d\n", sizeof(struct stat));
}
ralf@gandalf:~$ gcc t.c -I/usr/include/python2.2
-DUSE_PYTHON && ./a.out 
sizeof=96
ralf@gandalf:~$ gcc t.c && ./a.out 
sizeof=88
ralf@gandalf:~$ uname -a
Linux gandalf 2.4.18 #3 Thu Feb 28 16:29:52 CET 2002
i686 unknown

rechecked with gcc-3.2 and current HEAD.
Platform tests is Debian woody and Debian unstable.

Logged In: YES 
user_id=33168

The problem is that Python is built with large file support.
 I'm running RedHat and your example works the same for me.
 It appears that _LARGEFILE64_SOURCE (_LARGEFILE_SOURCE on
my system) is defined in pyconfig.h.  So __USE_FILE_OFFSET64
gets defined in /usr/include/features.h.

Python can be built without large file support, in which
case the size will not change.

Is this really a problem?  Can it be solved by removing
large file support from python?  Can you include
<sys/stat.h> before including Python.h to solve the problem?

Logged In: YES 
user_id=17929

Well, at least it was a problem for me. I built a shared C++
library, where one  of the classes had a private member of
type struct stat and a virtual destructor, and had some
subclasses of this class. 
Then I built a python module, linking against that library.
When deleting those subclasses I got segfaults and it did
take me pretty long to find out why this was happening
(assuming at first that I had buffer over/underruns, then
suspecting the compiler...). I essentially removed all of
the code from the library and it was still segfaulting. I
was really surprised when I changed that struct stat to a
character array of same size...
The problem here is within linux, if I would compile a
standalone C++ program with largefile support, linking
against that library, I would get the same results. But then
at least I would have known, that I didn't use standard
options to compile it.
A solution for this problem would be to add a warning to
python's documentation, or maybe move some of those defines
from pyconfig.h to a private header file (assuming here that
none of the structs declared in Python.h depend on struct
stat. If they did, including sys/stat.h before Python.h
might also be a bad idea).

Logged In: YES 
user_id=21627

Adding documentation is certainly possible, however: At what
places did you look  for documentation before writing your
module?

Changing the Python configuration process is not possible:
Python.h depends on various system headers. When those
headers get included, we *must* have the  LFS support
enabled, because it is not possible to include the system
headers a second time later.

Not including system headers is also not possible, since
Python.h provides API that relies on system headers, e.g.
functions taking FILE*.

I think this is really something for the C library to solve,
which should arrange for linker warnings if you try to
combine LFS objects with non-LFS objects. 

Logged In: YES 
user_id=17929

I read "Extending and Embedding the Python Interpreter". In
1.1 there would have been a hint:
"Since Python may define some pre-processor definitions
which affect the standard headers on some systems, you must
include Python.h before any standard headers are included. "
Funny thing here is that if I would have included
<sys/stat.h> before Python.h, I suppose my module would have
just worked...

Logged In: YES 
user_id=21627

Since that hint is already their since extending.tex 1.9, I
think we can close this.