Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add user override mechanism for CFFI foreign libraries #9

Open
dieggsy opened this issue Mar 9, 2025 · 1 comment
Open

Add user override mechanism for CFFI foreign libraries #9

dieggsy opened this issue Mar 9, 2025 · 1 comment

Comments

@dieggsy
Copy link
Collaborator

dieggsy commented Mar 9, 2025

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.

@dieggsy
Copy link
Collaborator Author

dieggsy commented Mar 11, 2025

In addition to overriding the path, a used may want to override the specific library used (e.g. prefer libiodbc even if unixodbc is installed), which is not easy on either platform currently.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant