[Openmcl-devel] shared libs on Darwin

Michael Klingbeil michael at klingbeil.com
Mon Jul 1 00:51:52 PDT 2002

Clearly this is a bit more complicated than I originally thought. 
Your detailed message was elucidating. I spent some time looking 
through ccl:level-0;l0-cfm-support.lisp to really try to understand 
the whole thing (which I have probably only partially succeeded at 

I'm not yet sure about this, but it seems to me that walking the 
internal _dl_loaded (or its Darwin equivalent) may not be entirely 
necessary. Yes it is nice to have knowledge of other libs that were 
loaded due to external references, but is that really needed as long 
as we know about all of the libraries immediately referenced by the 
*eeps* table? In this case unloading would only be possible on those 
libraries within the internal *shared-libraries* table, but perhaps 
that is not too much of a restriction (especially since unload is 
only possible for Darwin modules). Similarly, for 
refresh-external-entrypoints, reopening everything on 
*shared-libraries* should give all of externally referenced libraries 
that are needed. (And I notice that revive-shared-libraries ends up 
calling xGetSharedLibrary anyway...). But probably there are 
additional things I'm missing.

Currently I think resolve-eep expects that if xFindSymbol succeeds 
then the library is already in *shared-libraries* (since this is 
always kept synchronized with the _dl_loaded list). But it should be 
possible to simply walk *shared-libraries*, and if the library 
implementing the symbol in question is not found, simply add it to 
*shared-libraries*. NSModuleForSymbol seems to be the closest thing 
to dladdr, and I'm not sure this is quite the right thing so this 
might need to be rethought as well. Dealing with .dylibs and versus 
modules seems to be another confusion.

>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.)

I wonder if it is possible to avoid the runtime warnings by first 
calling NSAddImage with the flag 
then call NSAddImage again to actually load the dylib. Something like 
this (untested):

(defun open-dylib (name)
   (with-cstrs ((name name))
     (let ((res (#_NSAddImage name (logior #$NSADDIMAGE_OPTION_RETURN_ON_ERROR
       (if (%null-ptr-p res)
         (#_NSAddImage name (logior #$NSADDIMAGE_OPTION_RETURN_ON_ERROR

Openmcl-devel mailing list
Openmcl-devel at clozure.com

More information about the Openmcl-devel mailing list