[Mono-list] OSX Class libraries

[Benjamin Reed]

On Saturday, February 8, 2003, at 11:45 AM, keith davey wrote:

> I've been testing this and seem to have it a problem.
> OSX has dynlib files, and I assume these are the same
> as
> .so files. However when I run a program which tries to
> load a dynlib I get this:
>
> ** (invoke.exe:507): WARNING **: Failed to load
> library libSystem.dylib (libSystem.dylib):
> libSystem.dylib is not a loadable module
> got wrong token: 0x00000001
>
> ** ERROR **: file loader.c: line 491
> (mono_get_method): assertion failed: (table ==
> MONO_TABLE_MEMBERREF)
> aborting...
> Abort
>
> Anyone know anything about dynLib files? I guess if we
> have a problem I could write a C so, that wraps the
> dynlib file and then call that from mono.

Libraries on MacOSX are not like most elf systems...  MacOSX  
differentiates between shared libraries and dynamically loadable  
modules (plugin).  It looks like it's trying to load libSystem.dylib as  
a bundle (loadable module), but it's a shared library.  That is bad.  =)

MacOSX's dynamic loader is described in detail in  
http://developer.apple.com/techpubs/macosx/DeveloperTools/MachORuntime/ 
MachORuntime.pdf

The short version is:

Dylibs are shared libraries.  They are linked to another library or a  
binary at build time, and can be linked against, but cannot be  
dynamically loaded without some tricks (dlcompat, a dlopen/dlclose  
emulation library for macosx does this).  Even with tricks they can't  
be dlclosed though.

Bundles are loadable modules (ie, plugins), and can be dlopened and  
dlclosed (and the macosx equivalents, using the native dyld loader).   
They cannot be linked against, though.

 From what I understand this is all just a side-effect of the Mach-O  
structure.  On elf systems, shared libs and modules have the same  
structure, and can be treated as either, in Mach-O this is not the case.