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.