site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Hi, Brent. _sjc_ On 16 Sep 2009, at 07:44, Brent Fulgham wrote: Hi, 4. CFLite (550) crashes on startup. Therefore I assume my problem is in my CFLite build, and more specifically in the initialization logic. I realized that I was not linking the objcrt.obj into CFLite.dll. This got _objc_init_image to be called, so I guess that's some progress. However, the program continues to fail at the exact same spot. CFString.c: Line 1224: return CFRetain(kCFEmptyString); // Quick exit; won't catch all empty strings, but most Where kCFEmptyString is declared as: CFString.c: Line 152: CONST_STRING_DECL(kCFEmptyString, "") Thanks, -Brent _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/stuart%40echus.demon.co.uk _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This is based on a quick scan through the CFLite 550 sources, so could be wrong. I think the short answer is the suggestion to disable Obj-C for CFLite. Look at CFRuntime.c around line 468. That "#if 0" is new, and stops defining the CFTYPE_ ... _OBJC macros as harmless. I think for all versions of OpenCFLite you want to change it to use those first versions rather than the ones which actually call into the obj-c runtime. I think this was the default behaviour for building on non-OS X in previous versions. To get the obj-c-CF bridge working, you need two things. On the CF side are the functions _CFRuntimeBridgeClasses and __CFISAForTypeID, which I'm amazed to discover are actually present in the CF source. (They we're missing in previous versions, so I had to patch them back in for PureFoundation). These basically set up the first long pointer of the CFType structure in exactly the same way as the NSObject ISA ivar, as a pointer to the class dispatch table. The second thing you need is some actual obj-c objects. Yeah :) The "Object" object which (used to, haven't checked) come with the obj-c runtime won't help. NSObject implements everything again from scratch, including the retain/release system. On OS X, CoreFoundation is definitely the junior member of the CF/Foundation partnership. As you can see from the CF code, whenever a function is called for a bridged object CF will try to dispatch a message to the Foundation/obj-c method before falling back on the CF code. (On OS X, NSObject and the bridged objects actually live inside the CoreFoundation library binary, rather than Foundation.framework.) But like I said above, for that to work you actually need some obj-c objects to be present. I think you get the crash because _CFISAForTypeID is being called in the creation method of every CFType and is copying junk from the bridge table, which hasn't been correctly populated. (Although -- and sorry, but I haven't had a chance to build and test this -- the table should just contain 0s, and you'd think the the runtime would take a NULL ISA as a hint to exit gracefully, but anyway...) So, yeah. CFLite doesn't need obj-c to work, so changing the definition of those macros should fix things. On Tue, Sep 15, 2009 at 6:27 PM, Brent Fulgham <bfulgham@gmail.com> wrote: The failure happens when attempting to call CFRetain on a static empty string CoreFoundation object: This email sent to stuart@echus.demon.co.uk This email sent to site_archiver@lists.apple.com