SDL / Cocoahelper

[Joe McGuckin]

I have been struggling with this all day. I have the SDL framework installed. I built the helper (I has to add -F/Library/Frameworks to the Makefile).

Going back in to sbcl and running (ql:quick load "lisp builder-sdl") results in:

* (ql:quickload "lispbuilder-sdl")

To load "lispbuilder-sdl":

  Load 1 ASDF system:

    lispbuilder-sdl

; Loading "lispbuilder-sdl"

..

debugger invoked on a LOAD-FOREIGN-LIBRARY-ERROR:

  Unable to load any of the alternatives:

   ((:FRAMEWORK "cocoahelper") (:DEFAULT "cocoahelper"))

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):

  0: [RETRY          ] Try loading the foreign library again.

  1: [USE-VALUE      ] Use another library instead.

  2: [TRY-RECOMPILING] Recompile cocoahelper and try loading it again

  3: [RETRY          ] Retry

                       loading FASL for #<CL-SOURCE-FILE "cocoahelper" "cocoahelper" "cocoahelper">.

  4: [ACCEPT         ] Continue, treating

                       loading FASL for #<CL-SOURCE-FILE "cocoahelper" "cocoahelper" "cocoahelper">

                       as having been successful.

  5: [ABORT          ] Give up on "lispbuilder-sdl"

  6:                   Exit debugger, returning to top level.

Any ideas?

[Elliott Slaughter]

Depending on where things are located, it may be that you need to set cffi:*darwin-framework-directories* to include the appropriate paths:

http://common-lisp.net/project/cffi/manual/html_node/_002adarwin_002dframework_002ddirectories_002a.html

That said, these sorts of errors can also result from the dependencies of frameworks failing to load. Each framework has a path embedded for each framework it depends on, and if these paths don't match reality, then you'll get an error trying to load the framework. This has been a problem with Macports historically, because they hard-coded the install path into the framework, so you couldn't move the file around (or give it to another person). You can check these paths with the otool command. So for my version of SDL, I see:

$ otool -L /Library/Frameworks/SDL.framework/SDL
/Library/Frameworks/SDL.framework/SDL:
    @executable_path/../Frameworks/SDL.framework/Versions/A/SDL (compatibility version 1.0.0, current version 1.0.0)
    /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox (compatibility version 1.0.0, current version 1.0.0)
    /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit (compatibility version 1.0.0, current version 1.0.0)
...

In this output, @executable_path is relative to where the executable is, which in this case is the directory containing SBCL. There is also @loader_path which is relative to the location of the dynamic library. See:

https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/dyld.1.html

Hope that helps, and good luck!

--
You received this message because you are subscribed to the Google Groups "Lispbuilder" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lispbuilder...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Elliott Slaughter

"Don't worry about what anybody else is going to do. The best way to predict the future is to invent it." - Alan Kay