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 _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
