Re: find-foreign-library: recommend usnig modules

Kevin Rosenberg <kevin-HJRc7zDS/[email protected]> Wed, 24 Apr 2002 14:34:40 -0600
Newsgroups gmane.lisp.uffi.general
Message-ID <[email protected]>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Apr 24, 2002 at 01:05:11PM +0200, Hoehle, Joerg-Cyril wrote:
> 1) I strongly encourage use of module nicknames.
> I.e. don't say "required by Lispworks", say "recommended and makes
> your life easy and your work more likely to be portable".
> Similarly for DEF-FUNCTION.

That sounds like good advice. Currently, only Lispworks native FFI can
utilize a module nickname.

> "Even if your system doesn't need the indication of the module from
> which the function originates, we recommend specifying it via the
> :module option to UFFI:DEF-FUNCTION, for portability."

> CLISP will also require something like that for functions based on
> shared libraries, e.g. zlib.dll. It also has foreign functions not
> based on shared libraries, but on modules.

Ah, with two systems using nicknames, I agree that it makes sense to
urge the UFFI user to use them.

> 2) How to recogize cygwin? It appears as #+UNIX in CLISP, not as
> #+WIN32, but wants "cygz.dll" instead of "libz.so" which I suppose
> works across several UNIX systems (maybe only the dlopen() ones, not
> shl_load()), while #+WIN32 (native port, e.g. using MS-VC) wants
> "zlib.dll"

Interesting problem.
 
> So even the suffix is different among #+UNIX. This works against the
> default of NIL in :TYPES of uffi:find-foreign-library, doesn't it?

It does. A NIL TYPE should provide the default type for the system.
Perhaps the CLISP/CYGWIN issue can be identified by a unique combination
of *features* elements. 

> So providing a user settable variable
> (defvar *zlib-path*
>   (or #+WIN32 "zlib.dll"
>       ;; TODO how to deal with cygwin (#+UNIX on MS-Windows)? -- it wants "cygz.dll"
>       #+UNIX "libz.so"
>       #+AMIGA "zlib.library"
>   )
>   "Set this variable to point to the location of the zlib library
> (libz.so or zlib.dll) on your system.")
> is what people are used to and maybe the best one can have. Cygwin
> users will have to overide this. HP-UX users probably also.
 
Sure, one can alway skip using find-foreign-library and just use
load-foreign-libary without an automated sort.

> Or
>     #+(and CLISP UNIX) "so"
>     #+(and CLISP UNIX) "dll" ; for cygwin
>     #+(and CLISP UNIX) xyz ; for HP-UX
>     #+(and CLISP AMIGA) "library"

That'd be fine, but still have to have CLISP identify cygwin environment
so can use "dll" type.

> Problem: find-foreign-library may locate wrong library in
> ready-to-use binary distributions, i.e. archives which already
> contain both windows/zlib.dll and linux-libc6/libz.so...

Yes, that is the risk associated with having an automated library
search.  In general, I believe the benefit outweighs the risk. The
risk can be managed by having the user, on a system with multiple
library versions, order the items to be search, or on a very complex
system, choose not to use find-foreign-library.

Great thoughts, thanks for your continued contributions.

- -- 
Kevin Rosenberg
kevin-HJRc7zDS/[email protected]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8xxbdES7N8sSjgj4RAkXaAJ9BC865ePhM6cfFn6XUrwLXHosAPgCdFZpa
XXFYZmxrnYVUvb+lgGOg/A0=
=jJF0
-----END PGP SIGNATURE-----