| msg12728 - (view) |
Author: Matthias Klose (doko) *  |
Date: 2002-10-10 19:44 |
| 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. |
|
|
| msg12729 - (view) |
Author: Neal Norwitz (nnorwitz) * |
Date: 2002-10-10 22:22 |
| 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? |
|
|
| msg12730 - (view) |
Author: Ralf Schmitt (titty) |
Date: 2002-10-11 11:02 |
| 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). |
|
|
| msg12731 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2002-10-13 11:21 |
| 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. |
|
|
| msg12732 - (view) |
Author: Ralf Schmitt (titty) |
Date: 2002-10-14 13:00 |
| 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... |
|
|
| msg12733 - (view) |
Author: Martin v. Löwis (loewis) * |
Date: 2002-10-26 14:59 |
| Logged In: YES user_id=21627 Since that hint is already their since extending.tex 1.9, I think we can close this. |
|
|