"John Abel" <john.abel@pa.press.net> writes: > OK, I can see why Python.h has to be first, but surely, abiding by the spec > shouldn't prevent code from executing properly? Should I raise a bug report > for this? For what? That you can't compile a certain Solaris header, if the application adds some system-specifed #defines? That is a Solaris bug, not a Python bug. All system headers ought to work under _LARGEFILE_SOURCE and _FILE_OFFSET_BITS=64. > I'm guessing that only Solaris is affected (though maybe other > BSD-types are, too? AFAIK, only Solaris has the /proc oddity). I'd > like to be able to produce compliant modules. I'd like to help, if > I can. I don't see that Python can or should change here. We have to define _FILE_OFFSET_BITS, and we have to define it consistently across all object files, or else we can't free exchange data structures which contain off_t fields across functions. Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4