There are about a half a dozen ways to do that. It depends on your
target settings and other project specifics.
I would start by reading the Xcode documentation like
<file:///Developer/ADC%20Reference%20Library/documentation/MacOSX/
Conceptual/BPFrameworks/Tasks/ExportingInterfaces.html#//apple_ref/
doc/uid/20002260>
Or asking on the Xcode mailing list.
You might get away with something simple like:
#pragma export on
void MyPluginInitialize(void);
#pragma export off
You can use the nm tool in terminal on your bundle binary to see
what symbols are exported.
I should also mention that CFBundleCreate can return NULL which
would cause problems in your example code.
Thanks Jack.
I fumbled around the dynamic library design guidelines here: http://
developer.apple.com/documentation/DeveloperTools/Conceptual/
DynamicLibraries/Articles/DynamicLibraryDesignGuidelines.html#//
apple_ref/doc/uid/TP40002013-SW17
And it turns out there are these awful looking things called "module
initializers" which can also be used on applications, and as luck
would have it, bundles too. Basically the module initializer is
called as the bundle loads so it's possible to do any required setup
in a function flagged as the initializer.
Also found something similar to mark functions for export
Here's what I came up with in case anyone else needs to load and load
bundles that use Cocoa code from Carbon host applications:
// Define a function as the load time initializer:
LOAD_INITIALIZER
static void DoLoadTimeInitialization()
{
if (gCocoaInitialized == NO)
{
NSApplicationLoad();
gCocoaInitialized = YES;
}
}
// Define a function for export
EXPORT_SYMBOL
void SayHelloInSpanish()
{
NSLog(@"Hola");
}
With an initializer defined, CFBundleGetFunctionPointerForName works
as one would expect.
Ken
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
