The work so far on the CFFI port depends on cffi:define-foreign-library and cffi:load-foreign-library. We attempt to provide defaults that "should" work in the foreign library definition, but it's possible some users may need or want a more custom setup.
The variable clsql:*foreign-library-search-paths* is insufficient for this, because it is searched as a backup to default system locations, which may already contain an unwanted version of a foreign library.
On Linux, this seems trivially solved by LD_LIBRARY_PATH.
On macOS DYLD_LIBRARY_PATH is inherited by child processes by default, which poses an issue for:
- Any lisp called as a sub-process
- At least homebrew's distribution of SBCL since it's distributed with a shell script wrapper.
It seems possible to define, for example, clsql:*libodbc-library*, which would be NIL by default, but could be bound by a user to a pathname or their own CFFI foreign library definition. If this variable were bound, we would try loading this instead of the defaults.
The work so far on the CFFI port depends on
cffi:define-foreign-libraryandcffi:load-foreign-library. We attempt to provide defaults that "should" work in the foreign library definition, but it's possible some users may need or want a more custom setup.The variable
clsql:*foreign-library-search-paths*is insufficient for this, because it is searched as a backup to default system locations, which may already contain an unwanted version of a foreign library.On Linux, this seems trivially solved by
LD_LIBRARY_PATH.On macOS
DYLD_LIBRARY_PATHis inherited by child processes by default, which poses an issue for:It seems possible to define, for example,
clsql:*libodbc-library*, which would beNILby default, but could be bound by a user to a pathname or their own CFFI foreign library definition. If this variable were bound, we would try loading this instead of the defaults.