How CLSQL finds and loads foreign libraries

Hi,
>>>	* modules/bindings/win32/win32.lisp: use full paths for :LIBRARY
>>>	arguments (needed on cygwin)
>That's a pity.  Isn't there a way for CLISP to find out whether it's
>on Cygwin and only then demand the full path.
How should that work from within e.g. a library like cl-sql?
Your use of "demand" is unclear to me.

>How does CVS CLISP deal with this problem?  If I understand you
>correctly I could up until now write "kernel32.dll" and now I have to
>write "C:\\WINDOWS\\system32\\kernel.dll"

You can still write kernel32.dll, but that apparently won't work for people using a cygwin-based clisp (not tested myself).
One work-around is to take advantage of the fact that the ffi:def-call-out :library argument is evaluated, do use something like:

(defparameter +system32+
 (load-time-value(ext:string-concat (ext:getenv "WINDIR") "\\system32\\")))
(defparameter +kernel32+ (load-time-value (ext:string-concat +system32+ "kernel32.dll")))
(def-call-out GetCommandLineA (:library +kernel32+)
  (:arguments) (:return-type c-string))
-- Actually, LOAD-TIME-VALUE is superfluous when used in this way.

When loading the .fas file, the directory will be determined, according to the user's configuration.
However, if you save the result to an image, that image will most likely not be able to restore the foreign function on another machine with a different directory structure (untested).

>Hmm...
I agree with you.
So far, I myself would continue with relative paths, and hope for a cygwin specific fix from within clisp itself...
Like you said somewhere else, it makes a lot of sense when Lisp's loading of foreign libraries mimics that ot the host OS.

Regards,
	Jorg hohle.