Hello. The CFFI manual says [1] that cffi:use-foreign-library is intended to be the top-level form used idiomatically to go ahead and load the library. And most developers follow this idiom. I would argue that this is inconvenient. My motivation is that cl-test-grid tests (ql:quickload) of every ASDF system in Quicklisp, and the presence of cffi:use-foreign-library as a top-level causes failures of system load if the foreign library is absent. In other words, I can not test compilation of Common Lisp code until the foreign library is provided. You may object that cl:compile-file does not execute top level forms. But by compilation I mean at least asdf:compile-op of ASDF system. ASDF systems consist often of several files which depend on each other, and in order to compile dependent files ASDF should not only compile, but also load the dependency files. For example, (asdf:operate 'asdf:compile-op :cl+ssl) fails with: Unable to load foreign library (LIBSSL). Error opening shared library libssl32.dll : %1 is not a Win32 executable . [Condition of type CFFI:LOAD-FOREIGN-LIBRARY-ERROR] I think better idiom would be to not use top-lovel cffi:use-foreign-library, but instead have CL libraries to provide initialization routine which loads the foreign libraries. A supporting argument against top-level cffi:use-foreign-library is that as far as I know when we save an image of lisp, many lisps will not reload the foreign libraries when we load the image next time. I.e. the lisp image does not contain information about loaded libraries. Here, even with the approach with top-level cffi:use-foreign-library the CL library anyway needs to provide a routine to load the foreign library. Therefore, we could avoid the top-level cffi:use-foreign-library at all. I would like to know the opinion of CFFI developers. Do I miss anything? What are the reasons to support the top-level cffi:use-foreign-library? Best regards, - Anton [1] - http://common-lisp.net/project/cffi/manual/html_node/use_002dforeign_002dlib...