Hi all, I've been working on trying to get the latest Mono drop to work on Mac OS X, which also means that I've been trying to get Glib 1.3 to work, too. The latest problem that I've been having is with gmodule, and how Apple makes the distinction between plugins/modules and dynamic shared libraries.
Basically, the distinction is this from what I grok of the developer docs: Mach-O Bundle files (.bundle extension) are roughly analogous to our notion of a module... Dynamic code that can be linked and unlinked at runtime by an application. However, Mac-O Dylib files (.dylib extension) are analogous to shared libraries, and can be linked at runtime, *but not unlinked*. There are two ways to build gmodule on OS X: With dlcompat, or without (which defers to the gmodule_dyld.c implementation). Both do the same thing, and handle loading bundle code. This is great, but Mono (and I think several other applications) also make a habit of using gmodule to provide a platform agnostic means of loading shared libraries. (For example, Mono will bind libc and libm at runtime in the loader code.) This is a huge problem... Now, what I did to fix this was this: I'm thinking that the dylib behavior is essentially the same as making a normal gmodule resident, so I just added code that tries to load the requested module as a dynamic library if it fails to load as a bundle. (Basically, just try NSAddImage in _g_module_open() and NSLookupSymbolInImage in _g_module_symbol if the existing code fails prior to bailing...) My question is: Is this okay? _______________________________________________ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
