[Pythonmac-SIG] wxPython build issue

[Bill Northcott]

On 04/02/2006, at 12:51 PM, Bob Ippolito wrote:
> All this POSIX compliance stuff was broken on Mac OS X 10.2, then  
> Apple 'fixed' it in 10.3, but it regressed in 10.4

 From what I have seen on the particular issue of strcasecmp(), that  
is backwards.  The headers were non-compliant in 10.3 and fixed in  
10.4.  Possibly it is different in respect of other issues.

> When 10.3 came out, a Python developer decided to turn on the POSIX  
> compliance junk.  When 10.4 came out, Guido's time machine was  
> apparently unavailable.

Of course whether or not POSIX compliance is useful or not is a  
subject for a long discussion which is better avoided right now.  I  
would just observe that in the case of strcasecmp() there is no doubt  
which header file provides it in a POSIX environment.  Whereas the  
autoconf macro currently used gives no useful information.
>
> In my current branch for universal binaries, the configure script  
> will once again assume Mac OS X is not POSIX compliant until proven  
> otherwise... even if compiled on 10.3.

It is certainly not POSIX compliant if you don't define _POSIX_C_SOURCE.
>
> Mac OS X applications can not be built with _POSIX_C_SOURCE is  
> defined, period (pure Darwin stuff doesn't count, obviously).

I will take your word for that, but I might try to do it anyway.
>
> This is an Apple bug, not a wxPython bug... unless wxPython goes  
> out of its way to make that #define like Python does in this  
> particular case.
>
There certainly seems to be a bug in fp.h.  The comments in fp.h  
regarding rinttoll() etc. say they are not available in MacOS X but  
they are getting declared which is the problem I have left.

Cheers
Bill