I believe there is a problem with how fli:register-module is called
(this is on LispWorks 5.0.1) when the application uses
load-foreign-library. The short story is that this is causing
load-foreign-library to throw an error on LispWorks.
Long story...assume that I haven't added anything to
*foreign-library-directories* and consider the following
(cffi:load-foreign-library "user32.dll")
This causes cffi::load-foreign-library-helper to be called because
I'm passing a string rather than a symbol. Thus we
call cffi:load-foreign-library-path, passing nil for the library
parameter, which calls the LW-specific %load-foreign-library
function. That ends up calling fli:register-module which apparently
wants a non-nil value for its first argument. Like so:
CL-USER 5 > (fli:register-module nil :connection-style :immediate
:real-name "user32.dll")
NIL
CL-USER 6 > (fli:register-module 'mylib :connection-style :immediate
:real-name "user32.dll")
MYLIB
The latter is effectively what happens when the application uses
define-foreign-library and then use-foreign-library, and I confirmed
that this latter approach works where load-foreign-library doesn't.
I'm not sure what the proper fix is (i.e., creating a symbol out of
the path string might not be such a hot idea), otherwise I'd offer a
patch.
BTW, I think this may be a behavioral change going from LW 5.0 to 5.0.1,
because I don't remember having this problem on 5.0.
--
Jack Unrue