[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: loadlib for Mac OS X
- From: Asko Kauppi <asko.kauppi@...>
- Date: Thu, 23 Dec 2004 22:25:38 +0200
Just do it. Either way. :) I'm rather surprised that the importance(?)
of an OS X specific implementation detail has gained such audience. As
I said, Just do it.
23.12.2004 kello 21:04, E. Wing kirjoitti:
Hello, sorry, but I missed some of this discussion thread. I have
always been thoroughly confused by this subject, but I've also been
under the impression that I'm not alone in being confused.
But I thought I would try sharing what little I know in case it might
be helpful. If not, feel free to disregard.
Unlike the ELF format which most Unix people are familiar with, the
Mach-O format makes a distinction between "Shared Libraries"
(.dylib's) and "Loadable Modules" (bundles). In ELF you can use the
same .so to cover both tasks (i.e. link against at compile time or
dlload at run time).
But with Mach-O, you are expected to separate these tasks. You cannot
link against a bundle and you really aren't supposed to dynamically
load a dylib. I've heard of people dynamically loading dylibs, but
there are caveats with doing so. I think the big one is that a dylib
cannot be unloaded once loaded. But if you must do this, dlload() has
interfaces to NSModule/NSObjectFileImage() and such (that you already
identified) which will do the task. I think this practice may be
frowned upon though.
Bundles have no official extension. I think Next/Apple intended people
to pick their own extensions for their specific applications. But a
lot of Unix people started carrying over the .so extension for
everything which I think helped confuse the issue.
(This gets further confused by Next/Apple's Framework concept which
seems to be a glorified wrapper for a .dylib. It's confusing for Unix
oriented people, but they're actually really nice when you have to
start deploying/sharing software IMHO.)
So I think you're on the right track with NSModule/NSObjectFileImage.
A reassurance: despite the NS prefix, these functions in
<mach-o/dyld.h> have no dependencies on Objective-C, Foundation, or
AppKit. There is no Carbon requirement either. I ran into this on
another project and was pleasantly surprised that I didn't need any
There is a book called Mac OS X Panther for Unix Geeks that has a
small chapter on this with some example code. p.141-147. They use the
stuff in <mach-o/dyld.h> as you are doing to load a bundle. Though I
don't think they bother loading a .dylib, possibly for good reason.