On 9-feb-2006, at 1:50, Bill Northcott wrote:
On 09/02/2006, at 5:45 AM, Ronald Oussoren wrote:#define _POSIX_C_SOURCE 200112L #include <Carbon/carbon.h> int main () { }Is that a valid POSIX program? Don't define _POSIX_C_SOURCE if you usesystem libraries that are not part of POSIX.It is valid if somewhat minimal program in both C and C++. As far as I understand the Posix etc. standards, they define system library functions which must be provided, along with their functional definitions and the headers which must be used to access them. A C program is valid POSIX code if it uses the POSIX definitions of the system functions and includes. You can use any other libraries you like as long as they do not use any of the POSIX function names. So, yes I think that is valid POSIX C code.The real problem here is that C++ is not part of the POSIX standard. So no C++ program can be POSIX compliant. That is why the 'correct' tm fix is to conditionalise the POSIX defines with #ifndef __cplusplus or an equivalent. I have now established that if that is done all of WXPython will build perfectly happily.
This has nothing to do with C++ vs. C, but that Carbon/Carbon.h is not POSIX compliant (and that's likely also true for other Apple headers).
Ronald
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
