Re: How CLSQL finds and loads foreign libraries

On Fri, 22 Apr 2005 13:44:52 -0600, Kevin Rosenberg <kevin-HJRc7zDS/[email protected]> wrote:

> Edi Weitz wrote:
>> OK, I'll try to come up with something that's clean and works.  But
>> probably not in the next days.  I'm busy with other things and of
>> course I'll also be at the European Common Lisp Meeting this
>> weekend.
>
> That'd be great. And, of course, "clean and works" is a great thing.

So, yeah, it took me some time to get back to this.  I investigated
this a bit tonight and the actual culprit isn't CLSQL but rather
UFFI's LOAD-FOREIGN-LIBRARY.  The function's definition starts with

  (when (and filename (probe-file filename))

so if FILENAME isn't a path spec denoting the full path to a shared
library you can't load it.

Now, suppose we have PostgreSQL's libpq installed in a standard
location, like in /usr/lib/libpq.so on Linux/Unix or in
C:\WINDOWS\system32\libpq.dll on Windows.  The following operators
will find and load the library if /only/ the string "libpq.so" (or
"libpq.dll") is provided:

  LispWorks:  FLI:REGISTER-MODULE
  AllegroCL:  LOAD
  CMUCL:      SYS::LOAD-OBJECT-FILE
  SBCL:       SB-ALIEN:LOAD-SHARED-OBJECT
  OpenMCL:    CCL:OPEN-SHARED-LIBRARY

The first four I've tested myself, for OpenMCL I gather this from the
docs.  Don't know about MCL.

What doesn't work this way is SBCL's SB-ALIEN::LOAD-1-FOREIGN (which
is deprecated anyway) and CMUCL's (and most likely SCL's)
ALIEN:LOAD-FOREIGN.  The latter is only used for non-shared libraries
and I question its usefulness in UFFI because the idea of UFFI is to
provide a cross-platform layer and few (if any) other Lisps can load
non-shared libraries at all.

So, my proposal is to change UFFI:LOAD-FOREIGN-LIBRARY to accept
strings like "libpq.so" and "libpq.dll" which will be handed over
unmodified to the corresponding implementation-defined
functions/macros.

This proposal implies that support for ALIEN:LOAD-FOREIGN and friends
(CMUCL, SCL, old SBCL versions) will be dropped and that the
SUPPORTING-LIBRARIES argument will no longer be needed.  (Well,
actually it doesn't have to be dropped if you really want to keep it.
One should just check with PROBE-FILE before calling these functions.
I'm wondering if this functionality is really needed, though.)

Benefits: It'll be much easier to implement UFFI-based solutions (like
CLSQL) that just Do The Right Thing[TM] as far as loading of libraries
is concerned.

If you agree that this is a good idea I'll try to provide patches for
UFFI (including docs) and CLSQL.

Let me know what you think.

Cheers,
Edi.