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

[Leo]

On 2010-09-11 04:41 +0100, Gary Byers wrote:
> 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.

Many thanks for this explanation.

cl-plplot uses:

(defun load-libraries ()
  ; linux
  (pushnew #P"/usr/local/lib/" *foreign-library-directories* :test #'equal)
  ; OS-X / fink
  (pushnew #P"/sw/lib/" *foreign-library-directories* :test #'equal)
  ; OS-X / darwinports
  (pushnew #P"/opt/local/lib/" *foreign-library-directories* :test #'equal)
  (pushnew #P"/usr/local/unix/plplot/lib/" *foreign-library-directories* :test #'equal)
  (define-foreign-library libplplot
    (t (:default "libplplotd")))
  (use-foreign-library libplplot)
  (format t "libplplotd library loaded~%"))

(load-libraries)

to load and that stops working.

Change the define-foreign-library bit to:

  (define-foreign-library libplplot
    (:darwin "/usr/local/unix/plplot/lib/libplplotd.dylib")
    (t (:default "libplplotd")))

makes it work again.

Don't know why it was working previously for a long time.

Regards,
Leo