James Bielman wrote:
FOREIGN-FUNCALL-IN-LIBRARY
No, because foreign-funcall takes a pointer. That means, the name to address resolution has already happened before. Oops, wrong. foreign-funcall-pointer takes a pointer. foreign-funcall takes a string, which indeed means it's on its own w.r.t. address resolution :-(
perhaps silently ignoring :LIBRARY options on those implementations
We had the "uniformity" topic recently. Remember, I had to send patches to several packages to add :module to UFFI code to make it work with CLISP.
(with-default-library ("msvcrt.dll") (defcfun "sprintf" :int
Quite reasonable, as one can expect many files to have this structure: binding-to-XYZ.lisp (set-library-somehow XYZ) (defcfun x [in XYZ]) (defcfun y [in XYZ])
Regards, Jorg Hohle