Re: obcj4/CFLite on Windows
Re: obcj4/CFLite on Windows
- Subject: Re: obcj4/CFLite on Windows
- From: Stuart Crook <email@hidden>
- Date: Wed, 16 Sep 2009 12:04:54 +0100
Hi, Brent.
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.
_sjc_
On 16 Sep 2009, at 07:44, Brent Fulgham wrote:
Hi,
On Tue, Sep 15, 2009 at 6:27 PM, Brent Fulgham <email@hidden>
wrote:
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.
The failure happens when attempting to call CFRetain on a static
empty
string CoreFoundation object:
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden