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 <[email protected]> wrote: > On Wed, Jul 18, 2012 at 8:10 PM, Ryan Schmidt <[email protected]> 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 [email protected] > wandering unix systems administrator (available) (412) 475-9364 vm/sms >
_______________________________________________ macports-users mailing list [email protected] http://lists.macosforge.org/mailman/listinfo/macports-users
