I've observed what appears to be a bug on Windows using CCL 1.8 & the latest CFFI version from Quicklisp (0.10.7.1).
It seems *FOREIGN-LIBRARY-DIRECTORIES* is not being read correctly. I've placed `sqlite3.dll` in `C:\users\ralphm\temp\lib`. Below are the results of evaluating `(cffi:load-foreign-library '(:default "sqlite3"))` for different values of *FOREIGN-LIBRARY-DIRECTORIES*. It appears the trailing `/` is required but I haven't seen this documented in the manual - is this intended behaviour?
'("c:/users/ralphm/temp/lib/") ==> #<FOREIGN-LIBRARY DEFAULT-3009 "sqlite3.dll">
'(#p"c:/users/ralphm/temp/lib/") ==> #<FOREIGN-LIBRARY DEFAULT-3009 "sqlite3.dll">
'("c:/users/ralphm/temp/lib") ==> Unable to load foreign library (DEFAULT-3009). Error opening shared library sqlite3.dll : The specified module could not be found. .
'(#p"c:/users/ralphm/temp/lib") ==> Unable to load foreign library (DEFAULT-3009). Error opening shared library sqlite3.dll : The specified module could not be found. .
Cheers, Ralph
Ralph,
what you observe is not a bug in CFFI, but a feature of the Common Lisp pathname system. The *FOREIGN-LIBRARY-DIRECTORIES* contains a list of pathname designators. When a string is used as a pathname designator (either by putting a string onto that list or by using the #P reader macro to parse it into a pathname object), the last component of the string is considered to be a file name, not a directory component. It is possible to specify an empty file name in a string used as pathname, though.
To wit:
CL-USER> (describe #P"foo") #P"foo" Type: PATHNAME Class: #<BUILT-IN-CLASS PATHNAME> TYPE: (PATHNAME . #<CCL::CLASS-WRAPPER PATHNAME #x300040039D2D>) %PATHNAME-DIRECTORY: NIL %PATHNAME-NAME: "foo" %PATHNAME-TYPE: NIL [...] CL-USER> (describe #P"foo/") #P"foo/" Type: PATHNAME Class: #<BUILT-IN-CLASS PATHNAME> TYPE: (PATHNAME . #<CCL::CLASS-WRAPPER PATHNAME #x300040039D2D>) %PATHNAME-DIRECTORY: (:RELATIVE "foo") %PATHNAME-NAME: NIL %PATHNAME-TYPE: NIL [...]
The CL-FAD library is useful if you need to deal with directory specifications that do not conform to CL's pathname string parsing rules:
CL-USER> (describe (cl-fad:pathname-as-directory #P"foo")) #P"foo/" Type: PATHNAME Class: #<BUILT-IN-CLASS PATHNAME> TYPE: (PATHNAME . #<CCL::CLASS-WRAPPER PATHNAME #x300040039D2D>) %PATHNAME-DIRECTORY: (:RELATIVE "foo") %PATHNAME-NAME: NIL %PATHNAME-TYPE: NIL [...]
-Hans
On Fri, Nov 9, 2012 at 4:40 AM, Ralph Möritz ralph.moeritz@outlook.comwrote:
I've observed what appears to be a bug on Windows using CCL 1.8 & the latest CFFI version from Quicklisp (0.10.7.1).
It seems *FOREIGN-LIBRARY-DIRECTORIES* is not being read correctly. I've placed `sqlite3.dll` in `C:\users\ralphm\temp\lib`. Below are the results of evaluating `(cffi:load-foreign-library '(:default "sqlite3"))` for different values of *FOREIGN-LIBRARY-DIRECTORIES*. It appears the trailing `/` is required but I haven't seen this documented in the manual - is this intended behaviour?
'("c:/users/ralphm/temp/lib/") ==> #<FOREIGN-LIBRARY DEFAULT-3009 "sqlite3.dll">
'(#p"c:/users/ralphm/temp/lib/") ==> #<FOREIGN-LIBRARY DEFAULT-3009 "sqlite3.dll">
'("c:/users/ralphm/temp/lib") ==> Unable to load foreign library (DEFAULT-3009). Error opening shared library sqlite3.dll : The specified module could not be found. .
'(#p"c:/users/ralphm/temp/lib") ==> Unable to load foreign library (DEFAULT-3009). Error opening shared library sqlite3.dll : The specified module could not be found. .
Cheers, Ralph _______________________________________________ cffi-devel mailing list cffi-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel