[Openmcl-devel] Shared library bug?

[Gary Byers]

On Tue, 29 Jun 2004, Andrew P. Lentvorski, Jr. wrote:

> Is this a bug?
>
> Welcome to OpenMCL Version (Beta: Darwin) 0.14.2-040506!
> ? (open-shared-library "/Users/devel/lib/libgdk-x11-2.0.dylib")
> #<SHLIB /Users/devel/lib/libgdk-x11-2.0.dylib #x638EF46>
> ? (external "_gdk_draw_point")
> #<EXTERNAL-ENTRY-POINT "_gdk_draw_point" (#x006BC838)
> /Users/devel/lib/libgdk-x11-2.0.dylib #x638EE1E>
> ? (external "missingfuncbleahfoo")
> #<EXTERNAL-ENTRY-POINT "missingfuncbleahfoo" {unresolved}  #x638EBCE>
>
> The missing function just claims to be unresolved rather than
> completely missing altogether.  Is this expected?

It's intentional; the idea is that if you later open a library that
defines the unresolved entrypoint it can be resolved lazily.  (IIRC,
the PRINT-OBJECT method on an EXTERNAL-ENTRY-POINT will try to resolve
it and will fail quietly if that's not possible; calling an unresolved
EXTERNAL-ENTRY-POINT will try to resolve it and fail loudly.)

>
> Also, is there a way to get a list of the available functions
> associated with a loaded shared library from inside OpenMCL?  What I am
> trying to do is take the *.defs files from PyGtk (which are written in
> Scheme and match the Gtk interface) and map them into OpenMCL.  It
> would be useful to know which functions actually exist in the library
> to avoid mapping missing functionality.


I don't believe that there's anything (relatively) high level;
/usr/include/mach-o/dyld.h defines a few functions for
enumerating/iterating over the symbols in certain types of libraries.
It might be simpler for your purposes to parse the output of the "nm"
program.




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