![](https://secure.gravatar.com/avatar/183ec81bfdbe6442a896a43223281177.jpg?s=120&d=mm&r=g)
On Mon, Dec 21, 2009 at 1:26 PM, Luís Oliveira <luismbo@gmail.com> wrote:
I'm believe I'm seeing this issue again, but none of my previous workarounds seem to be working. I am using SBCL 1.0.29 on Windows XP, and when I save and run an executable, I keep getting undefined alien errors. I have
On Mon, Dec 21, 2009 at 8:55 PM, Elliott Slaughter <elliottslaughter@gmail.com> wrote: tried
both the :dont-save t hack that I initially suggested, and have tried calling (close-foreign-library ...) on all of the open libraries before saving the executable, and nothing helps.
Can you come up with a minimal test case? Something using e.g. libtest.dll would be nice.
I think I managed to reproduce this error, and this time, I have a minimal test case! When I put a dll on *foreign-library-directories* and build a Windows executable with SBCL, the generated executable cannot run unless the dll is present at exactly the same absolute path as it was during compile time. If I instead move the dll into the current working directory, then I don't have any problem with absolute paths being saved in my binary. First, the contents of break.lisp: (asdf:oos 'asdf:load-op :cffi) (use-package :cffi) (pushnew (truename #p"lib/") *foreign-library-directories* :test #'equal) (define-foreign-library sdl (:windows "SDL.dll")) (defun main () (use-foreign-library sdl) (format t "It works~%")) (main) (save-lisp-and-die "main.exe" :toplevel #'main :executable t) (quit) Second, I create two binaries. I demonstrate that the first executable is broken by moving the original lib directory after compiling, while the second executable works fine. $ ls * break.lisp bin: lib: SDL.dll $ sbcl --load break.lisp This is SBCL 1.0.29, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. [ ... ] It works [undoing binding stack and other enclosing state... done] [saving current Lisp image into main.exe: writing 2888 bytes from the read-only space at 0x22000000 writing 1736 bytes from the static space at 0x22100000 writing 27582464 bytes from the dynamic space at 0x22300000 done] $ mv main.exe bin/ $ cp lib/SDL.dll bin/ $ cd bin/ $ ./main.exe This is experimental prerelease support for the Windows platform: use at your own risk. "Your Kitten of Death awaits!" It works $ mv ../lib/ ../lib2 $ ./main.exe This is experimental prerelease support for the Windows platform: use at your own risk. "Your Kitten of Death awaits!" debugger invoked on a SIMPLE-ERROR: Error opening shared object "c:\\Users\\Elliott\\Programming\\CommonLisp\\brea k-cffi\\lib\\SDL.dll": 126. Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [CONTINUE ] Skip this shared object and continue. 1: [RETRY ] Retry loading this shared object. 2: [CHANGE-PATHNAME] Specify a different pathname to load the shared object fr om. (SB-SYS:DLOPEN-OR-LOSE #S(SB-ALIEN::SHARED-OBJECT :PATHNAME #P"c:\\Users\\Elliott\\Programming\\CommonLisp\\break-cffi\\lib\\S DL.dll" :NAMESTRING "c:\\Users\\Elliott\\Programming\\CommonLisp\\break-cffi\\lib\\S DL.dll" :HANDLE NIL :DONT-SAVE NIL)) 0] (quit) $ cd .. $ mv lib2/ lib $ cp lib/SDL.dll . $ rm bin/main.exe $ ls * SDL.dll break.lisp bin: SDL.dll lib: SDL.dll $ sbcl --load break.lisp [ ... ] It works [undoing binding stack and other enclosing state... done] [saving current Lisp image into main.exe: writing 2888 bytes from the read-only space at 0x22000000 writing 1736 bytes from the static space at 0x22100000 writing 27578368 bytes from the dynamic space at 0x22300000 done] $ mv main.exe bin/ $ cd bin/ $ ./main.exe This is experimental prerelease support for the Windows platform: use at your own risk. "Your Kitten of Death awaits!" It works $ mv ../lib/ ../lib2 $ ./main.exe This is experimental prerelease support for the Windows platform: use at your own risk. "Your Kitten of Death awaits!" It works -- 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