Re: How CLSQL finds and loads foreign libraries

Edi Weitz wrote:
> I've submitted patches for UFFI and CLSQL in summer 2005 (see subject
> line) which changed the way CLSQL tries to load the foreign libraries
> it needs.  The change was that short strings like "libmysql.so" should
> be tried first and only afterwards (in case of a failure) should full
> absolute pathnames like #p"/usr/lib/libmysql.so" be tried.  The result
> was that absolute pathnames weren't hard-coded into images delivered
> with Lisp implementations that can create "stand-alone" executables.
> This is the only way such an executable has a realistic chance to run
> on machines other than the one it was compiled on.

Yes, overall those patches were quite helpful.

> I haven't updated CLSQL for quite some time, but I recently did and it
> seems that in the current release (CLSQL 3.7.8 and UFFI 1.5.17) these
> changes were reverted and as a result all of the LispWorks executables
> (if they're using CLSQL) which I created for my customers are broken
> if I recompile them.  It seems the old pre-3.2.1 behaviour was somehow
> restored.  (I can't investigate when and how exactly this happened as
> I can't access the archive.)

Your changes were never "reverted", but additions and modifications to
the library code have been made over time to support other users /
features. Each time I've changed a file, I've made a note in ChangeLog
with a summary of the change.

> Was there a specific reason for this change?

Yes, I'm sure there was. I don't recall the details for the updates,
I'll have to review the changelog. But, the only reason for any
changes would be to support some user's need for library loading. I
regret those changes to support their needs affected the patches you
sent to support your needs.

Have you looked at the current library loading code? Your patches will
still be there, albeit with needed modifications over time. I can
email you old versions if you like to compare the current code to code
as it existed after your patches. If there's something we can fix
in the current code to support your needs, of course, I'm happy to do
so.

-- 
Kevin Rosenberg [email protected]