[Openmcl-devel] CCL64 fails to load cl-plplot

[Gary Byers]

I probably should have known; I think that the "missing architecture" case 
uses that term.

Whether or not you can do:

? (ccl:open-shared-library "/usr/local/unix/plplot/lib/libplplotd.9.8.0.dylib")

successfully might tell you something.  If that succeeds, then whatever CFFI (?)
was doing to tell the dynamic linker what directories to look in for relative
library pathnames might not work as it's supposed to.

OPEN-SHARED-LIBRARY just passes the namestring it receives and some options
to a dynamic linker function called dlopen(); if dlopen() fails, an error
is signaled (using the string returned by dlerror() as part of the error
message).  All of the heavy lifting - finding any other libraries that the
argument library depends on, resolving references to external symbols, making
the symbols defined by all loaded libraries globally available - is done by
dlopen(), and the only thing we can know about any problems that might have
occurred at any point in that process is what dlerror() tells us.

You're really asking "why does dlopen() fail to load a library on my system ?",
and the correct answer is "I don't know, and don't have a good way to know."

The error message that you got was:


Error opening shared library "libplplotd.dylib": dlopen(libplplotd.dylib, 10): image not found

e.g., dlopen() was trying to open the library via the relative pathname 
"libplplotd.dylib".  When looking for a library with a relative name, dlopen()
will search in any directories listed in the environment variables LD_LIBRARY_PATH
and DYLD_LIBRARY_PATH; you can see the values of these variables via CCL:GETENV,
e.g.:

? (ccl:getenv "LD_LIBRARY_PATH")

If that's non-null, it should be a colon-separated list of directories in
which dlopen() should look for a library

The "otool" program with the "-L" option will list the shared libraries used
by an executable file or shared library, so:

$ otool -L /usr/local/unix/plplot/lib/libplplotd.9.8.0.dylib

can be used to determine what libraries that library depends on.

I don't know of any recent change in CCL that'd affect this.  The thing
that comes closest is a change to force OPEN-SHARED-LIBRARY to call dlopen()
on the initial thread; some OSX shared libraries can only be opened on the
initial thread, some lisp libraries seem to be unaware of this, and that
change was supposed to at least allow users of those lisp libraries to get
to the point where they realized that lots of other things would need to
change.  Whether that workaround's a good idea or not, it's not clear to
me that it could affect whether or not a library's found or loaded correctly.



On Sat, 11 Sep 2010, Leo wrote:

> On 2010-09-11 01:46 +0100, Gary Byers wrote:
>> What output is produced by:
>>
>> ? (ccl:run-program "file" '("/usr/local/unix/plplot/lib/libplplotd.9.8.0.dylib")
>>         :output t)
>>
>>
>> I suspect that that'll tell you that that dylib is 32-bit only.
>
> ? (ccl:run-program "file" '("/usr/local/unix/plplot/lib/libplplotd.9.8.0.dylib")
>        :output t)
> /usr/local/unix/plplot/lib/libplplotd.9.8.0.dylib: Mach-O 64-bit dynamically linked shared library x86_64
> #<EXTERNAL-PROCESS (file /usr/local/unix/plplot/lib/libplplotd.9.8.0.dylib)[4892] (EXITED : 0) #x3020007FA50D>
>
> Leo
>
>