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