[Openmcl-devel] shared libs on Darwin

[Gary Byers]

One of the things that dlcompat didn't provide (as of the last time I
checked) is "dladdr", which returns information (containing library,
nearest symbol, etc.) about a given address.  OpenMCL uses this to
keep track of which library contains each external entry point; the
intent is that

  a) external entry points which refer to addresses in a given library
     are invalidated when the library is closed

  b) attempts to use invalidated ("unresolved") external entry points
     that are defined in a shared libray will try to re-open the library
     if necessary.

On Linux, OpenMCL uses dlsym() to resolve symbol addresses (for
bootstrapping reasons, lisp code calls into the lisp kernel (xFindSymbol(),
in "ccl:lisp-kernel;kernel-init.c") to do this.)  I believe that all of
the calls to dlsym pass a NULL "handle" argument (RTLD_DEFAULT, which
is one way of saying "look up the symbol globally".)  The last time I
checked, dlcompat's emulation of dlsym() didn't understand RTLD_DEFAULT
(or the similar RTLD_NEXT) pseudo-handle arguments.

The data structure that dlopen returns is largely opaque: there are
a few publicly-visible fields and a lot of private internal fields.
OpenMCL accesses one of the public fields (used to link open libraries
into a list) and, somewhat guiltily, a field that became private in a
recent version of libc.  The head of the linked list is accessible via
an exported global variable; OpenMCL walks the list whenever a shared
library is opened or closed (since that's the only way it finds out
about libraries that are transitively opened or closed.)  I don't
believe that dlcompat makes information about the shared libraries it
maintains globally available.

All of these considerations led me to conclude that dlcompat doesn't
help as much as it might appear to.  I -think- that this assessment
was reached after looking at the most recent version of dlcompat.

That said, I think that it's possible to support most features of
Darwin shared libraries with an interface that's similar to that that
exists for Linux.  (Oh, I suppose that esoteric, advanced features -
like closing a .dylib - might be impossible; to be fair, one of the
more interesting cases in which a shared library is closed is when
SAVE-APPLICATION is called.)

For heavyweight Darwin libraries (.dylibs) at least, it's possible to
enumerate open images (via #__dyld_image_count and #__dyld_get_image_header),
and it's possible to ask (via #_NSIsSymbolNameDefinedInImage) whether
or not a given loaded library image defines a foreign symbol.  That's
a lot of the functionality that OpenMCL needs to support "resolution
of symbols defined in application-loaded libraries from saved lisp
images", a feature that's clearly in desparate need of a more concise name.

Note that it's currently possible to open a .dylib via (of all things)
CCL::OPEN-DYLIB.  (In cases where I've used this, I've gotten runtime
warnings from malloc() on attempts to open a .dylib that's already
open.)   Someone reported a few months ago that they had success
in opening lighter-weight Darwin libraries ("bundles" ?) via things
like #_NSCreateObjectFileImageFromFile (IIRC); it -sounds- like it'd
be a good idea to make OPEN-SHARED-LIBRARY handle both types of Darwin
library.

I -think- that the priorities are:

  a) to make OPEN-SHARED-LIBRARY work reasonably with Darwin libraries
     (and to make CLOSE-SHARED-LIBRARY work when possible.)

  b) to keep track of which libraries define which external entry points
     (and, to the extent possible, of library dependencies)
     so that attempts to use (call) those entrypoints from a saved OpenMCL
     image work reasonably.

On Sun, 30 Jun 2002, Michael Klingbeil wrote:

> I noticed that the current documentation claims that
> OPEN-SHARED-LIBRARY and CLOSE-SHARED-LIBRARY are not yet supported on
> Darwin.
>
> If this is currently still the case, I was thinking that the dlcompat
> library by Jorge Acereda available at:
>
> http://fink.sourceforge.net/bindist/source/dlcompat-20020606.tar.gz
>
> might provide an easy and quick way to get this working under Darwin.
> It is a nice wrapper which provides dlopen, dlsym, dlerror, and
> dlclose without all the Darwin cruft.
>
> If this sounds like a reasonable course of action, I could try taking
> on this project myself (although I'm not yet familiar with building
> OpenMCL!). Or if there are others interested in doing this, please
> let me know. Thanks.
>
>
> Michael Klingbeil
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel
>
>


_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel