Problem with ECL (embeddable common lisp) 12.2.1 on Lion

[Robert P. Goldman]

That fasl (fast load) file is not the problem. It is recompiled as part of the testing process, so if it still references the stale libffi, then the ECL compiler is still referencing it, despite the port upgrade. So the port upgrade is not sufficient to fix the problem. I don't know enough about the mechanics to understand why the command Brandon supplied did not trigger a rebuilding of the ECL compiler, but it didn't.
Best,
R

Sent from my iPad

On Jul 18, 2012, at 19:22, Brandon Allbery <allbery.b at gmail.com> wrote:

> On Wed, Jul 18, 2012 at 8:10 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
> > "dlopen(/Users/rpg/lisp/asdf/tmp/fasls/ecl-12.2.1-unknown-macosx-x86/test/file3.fas,
> > 10): Library not loaded: /opt/local/lib/libffi.5.dylib
> >  Referenced from:
> > /Users/rpg/lisp/asdf/tmp/fasls/ecl-12.2.1-unknown-macosx-x86/test/file3.fas
> >  Reason: image not found")
> 
> I don't know what /Users/rpg/lisp/asdf/tmp/fasls/ecl-12.2.1-unknown-macosx-x86/test/file3.fas is, but that is what is referencing libffi, and that is what needs to be rebuilt now.
> 
> It's a Lisp fast-load image, which traditionally was a memory dump of the heap --- this is probably just the shared object version of that.  In any case it is more like an executable than a data file, and is now invalid unless ECL provides some way to poke inside it (unlikely).  It needs to be removed and regenerated, however ECL does that (I, hm.  Have not done a lot of Lisp, ignoring elisp, since the [unrelated!] MIT Maclisp).
> 
> -- 
> brandon s allbery                                      allbery.b at gmail.com
> wandering unix systems administrator (available)     (412) 475-9364 vm/sms
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20120718/3052ae18/attachment.html>