Woes with gmodule and Mac OS X (and possible solution)

[Ryan Wilhm <r_wilhm mac com>]

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?