[Pythonmac-SIG] wxPython build issue

[Kevin Ollivier]

Hi Bob,

On Feb 3, 2006, at 6:07 PM, Bob Ippolito wrote:

>
> On Feb 3, 2006, at 6:02 PM, Kevin Ollivier wrote:
>
>> On Feb 3, 2006, at 5:29 PM, Bill Northcott wrote:
>>
>>> On 04/02/2006, at 12:00 PM, Bob Ippolito wrote:
>>>> This is exactly what TigerPython24Fix is for:
>>>> http://undefined.org/python/#TigerPython24Fix
>>>
>>> As far as I can see this patch is a work around for the binary
>>> package on Bob's web site.  Kevin and I are trying to fix the source
>>> code.  so things build correctly without user level patching.
>>
>> Actually, if Python can get along without having _POSIX_C_SOURCE  
>> defined, then removing that define from Python itself is a very  
>> good idea. However, you're right that it only solves the immediate  
>> problem, still leaving the problem that wx cannot be built when  
>> _POSIX_C_SOURCE is defined.
>
> Mac OS X applications can not be built with _POSIX_C_SOURCE is  
> defined, period (pure Darwin stuff doesn't count, obviously).
>
> 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.

No, it doesn't, but it does determine which header file to get  
strcasecmp from at configure time, which is a bug because it may  
choose string.h at configure time, but later needs to get these  
functions from strings.h because the define of _POSIX_C_SOURCE  
changed. The fix for that bug would be to always use strings.h, at  
least on Tiger and up. Of course, since we'll still have the Apple  
bug with Carbon even if we use strings.h, we're better off just  
making sure _POSIX_C_SOURCE is undefined for wx, and thus string.h  
now always works with wx, solving both problems at once. :-)

Thanks,

Kevin

> -bob
>