We built a Framework and then separately compiled and linked the
useadd.c
module against it. The Framework was later placed in ~Library/Frameworks
, and the linker was able to load it at runtime.The other one was a Cocoa Bundle compiled separately and placed in a known directory, which a second project that is a command line tool searches to find it. Since the tool doesn't have a place to stash resources, that's a little awkward.
They have 3 more examples in the chapter. One has a module called
simplemessage.m
(no header) that is compiled as a "bundle" (though not the same as the real bundles) and given the extension .msg
. (It doesn't really matter what we use). Then, that code is loaded by a second module called bundleprinter
, which uses a bunch of functions from <mach-o/dyld.h>
:As I think you can see, this setup works, but the functions involved are all deprecated, so it seems pointless to go through it. The fourth example is an updated version of the same one which goes more smoothly. It uses functions declared in
<dlfcn.h>
: dlopen
and dlsym
. Their (simple version of the) plug-in is just this:I did not use the -g flag to the compiler because the resulting .dSYM file interferes with the loading, later. You could remove it after the build if you wanted. The code which finds and loads the plug-in is below. And the output is:
bundleprinter-dl.m
:The last example from this Chapter is one where a Framework is embedded in an application. That's for next time.