Re: How CLSQL finds and loads foreign libraries

On Thu, 21 Apr 2005 11:03:46 -0600, Kevin Rosenberg <kevin-HJRc7zDS/[email protected]> wrote:

> I agree that abstracting the foreign library loader code is a good
> idea. The abstracted code could go into a new file in the sql/
> directory and the specific loading specializations could go into the
> *-loader.lisp files in the db-mysql, db-postgresql, db-oracle,
> db-odbc, db-sqlite, and db-sqlite3 (whew!) directories.

Yep.

> Edi, I think your idea to have a way for the end-user to set local
> directories is a good idea so that the CLSQL source itself doesn't
> need to be edited by the end-user.

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.

> Michael, taking advantage of Windows ability to find shared
> libraries is an advantage. Does this only work if the directory with
> the shared library is the current PATH environmental variable?

Or in the current directory, or in the executable's directory, or in
the Windows directory, or in the Windows system directory.

  <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>

>From my understanding of the LW and AllegroCL docs they'll load a
shared library that doesn't have directory information in its pathname
just like the underlying OS would do it, so

* this should apply to Linux, Unix, OS X as well as to Windows,

* it'll basically work like with any old C program - if libfoo.so (or
  foo.dll) can't be found in one of several standard locations then
  the app will refuse to start.

I don't know yet about CMUCL, OpenMCL, and so on but I'll make sure
that a patch supplied by me will work with all supported Lisp
implementations except for the ones I can't test - those that need a
Mac or Sparc.

Cheers,
Edi.