Re: [Pyobjc-dev] 10.6: Twisty maze of build issues

[Aahz <aa...@py...>]

On Thu, Jan 14, 2010, Ronald Oussoren wrote:
> On 12 Jan, 2010, at 22:36, Aahz wrote:
>> 
>> Should I try just building PyObjC 2.2 from source?  I tried updating
>> macports before I realized that this was the system libxml.
> 
> Rebuilding pyobjc-core from source should fix the libxml issues, I
> created those binaries on 10.6 and that version of libxml is not
> compatible with the one on 10.5.

Okie-doke.

>> AFAICT, PyObjC 2.2b2 is crashing on 
>> 
>> from Foundation import NSAutoreleasePool, NSMutableArray, NSString
>> 
>> in objc._bridgesupport._parseBridgeSupport() with "ValueError: Unknown
>> typestr".  Assuming the line number matches the source, that's
>> 
>>            objc.parseBridgeSupport(data, globals, frameworkName, *args, **kwds)
> 
> Is this using /usr/bin/python?

Nope, still Python 2.6.4 from python.org, building on 10.5, running on
10.6.

>> OTOH, the app built with PyObjC 1.4 is crashing with
>> USING_FORK_WITHOUT_EXEC_IS_NOT_SUPPORTED_BY_FILE_MANAGER
>> and I'm not sure where.  Any clues?
> 
> Do you use os.fork in your program?  Apple's frameworks do not support
> calling fork without calling exec right after that, especially (but
> not limited to) frameworks that have a connection to the window
> server.  AFAIK that includes the CoreFoundation framework.

Which is stupid, bone-headed, and wrong.

Repeating from pythonmac-sig:

After a lot of poking around, it appears that platform.mac_ver() is
broken in 10.6 (Snow Leopard) because the gestalt module calls fork(),
which causes a crash with
USING_FORK_WITHOUT_EXEC_IS_NOT_SUPPORTED_BY_FILE_MANAGER.  This seems to
only happen with py2app builds; I have not been able to reproduce using
strict command-line testing, and I haven't had time to create a
stripped-down app to test with.

I'd appreciate if someone else could verify before I file a bug.  (It's
possible that the multiprocessing module is involved if a simple test
fails to reproduce -- my AppDelegate starts another process for the main
code that then calls mac_ver() to log the current OS version.)  I'm using
os.uname() instead for now.
-- 
Aahz (aa...@py...)           <*>         http://www.pythoncraft.com/

"If you think it's expensive to hire a professional to do the job, wait
until you hire an amateur."  --Red Adair