Gmane
Picon Favicon
From: Edi Weitz <edi@...>
Subject: How CLSQL finds and loads foreign libraries
Newsgroups: gmane.lisp.clsql.devel
Date: 2005-04-18 23:01:28 GMT (3 years, 11 weeks, 4 hours and 35 minutes ago)
Hi!

When using CLSQL I'm often not happy with the way CLSQL currently
tries to find and load foreign libraries, especially on Windows.  I'd
be willing to fix this myself but after thinking about the problems
involved a bit I'm not sure what would be the best way.  Here's some
food for thought:

1. Currently each backend which depends on foreign code has its own
   "loader" file.  They all seem to be quite similar although not
   exactly equal.  I think it should be feasible to generalize this a
   bit more.

2. Some backend loaders (notably the ones for Oracle and DB2) refer to
   environment variables which are usually used with these backends
   but most don't.

3. A couple of search paths are hard-coded but they are either
   specific to Unix/Linux (like "/usr/lib/") or obviously to one of
   Kevin's machines (like "/home/kevin/...").

4. The "loader" files not only define the special variables that are
   steering the search process but they also immediately try to load
   the foreign library so there's no way to intervene if your library
   happens to be located somewhere else.

I currently see two ways to provide a means for the user to change the
loading behaviour:

A. Define a special variable like *ffi-library-path* in the CLSQL
   package so that users can first load CLSQL, then modify this
   variable, then load the backend they want to use.  (Of course, in
   this case the backend loaders have to respect this variable.)

   The downside is that there'll be one variable for all backends
   which isn't very elegant if you use several backends at once.
   (Does anyone actually do this?)

   Another problem is that you can't simply write an ASDF system
   definition like

      (defsystem :foo
          ...
          :depends-on (:clsql-postgresql))

   anymore.

B. Modify the loaders so that they look into one or several
   environment variable(s) specific to CLSQL.  Not very Lisp-y but
   it's a work-around for the package hen-and-egg problem described
   above.

Both of these two options would be better for me than the current
situation (where I modify the loader files each time I download a new
CLSQL release) but they still look kind of kludgy.  Also, they don't
work pretty well with delivered executables.

I think the "real" solution would be to simulate how the corresponding
operating system looks for shared libraries.  For Windows this is
described here

  <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_The_Search_Path_Used_by_Windows_to_Locate_a_DLL.asp>

and at least for LispWorks I'd be able to code it using
LW:LISP-IMAGE-NAME and some FFI calls.  However, for other Lisps and
for Linux, OS X, FreeBSD, or Solaris I'm not sure how to do it
correctly (or if this is even possible from Lisp).

What do others think about this?  Or am I not seeing the wood for the
trees?

Cheers,
Edi.