[cffi-devel] [PATCH] fix %load-foreign-library on cmucl
on CMUCL it get an error when I load twice a library with LOAD-FOREIGN-LIBRARY because SYS::LOAD-OBJECT-FILE returns NIL when re-loading a shared object. the attached patch fixes this -- (sign :name "Stelian Ionescu" :aka "fe[nl]ix" :quote "Quidquid latine dictum sit, altum sonatur.")
On 12/6/06, Stelian Ionescu <stelian.ionescu-zeus@poste.it> wrote: (defun %load-foreign-library (name) "Load the foreign library NAME." - (sys::load-object-file name)) + (or (sys::load-object-file name) + t)) Hmm, that way %LOAD-FOREIGN-LIBRARY will never return NIL, even when loading the library really fails. We should be detecting if the foreign library is already loaded, and we should probably keep track of this in the portable side of things. That's needed for UNLOAD-FOREIGN-LIBRARY too, it's in the TODO list I think. You're welcome to tackle that TODO item. :-) -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/
On Fri, Dec 08, 2006 at 09:09:38AM +0000, Luís Oliveira wrote:
On 12/6/06, Stelian Ionescu <stelian.ionescu-zeus@poste.it> wrote:
(defun %load-foreign-library (name) "Load the foreign library NAME." - (sys::load-object-file name)) + (or (sys::load-object-file name) + t))
Hmm, that way %LOAD-FOREIGN-LIBRARY will never return NIL, even when loading the library really fails. We should be detecting if the foreign library is already loaded, and we should probably keep track check this new patch
of this in the portable side of things. That's needed for I'm not sure this can be done reliably, imagine for instance that someone may load libraries in their initialization file *before* loading cffi which would lead to incongruities between the lisp implementation and cffi; we should see first how many of the supported implementations have a means to see which foreign libraries have been loaded. on CMUCL there's SYS::*GLOBAL-TABLE*, on SBCL there's SB-ALIEN::*SHARED-OBJECTS* but I don't know about the others
UNLOAD-FOREIGN-LIBRARY too, it's in the TODO list I think.
You're welcome to tackle that TODO item. :-) I'll see what I can do
-- (sign :name "Stelian Ionescu" :aka "fe[nl]ix" :quote "Quidquid latine dictum sit, altum sonatur.")
Stelian Ionescu wrote:
On Fri, Dec 08, 2006 at 09:09:38AM +0000, Luís Oliveira wrote:
On 12/6/06, Stelian Ionescu <stelian.ionescu-zeus@poste.it> wrote:
(defun %load-foreign-library (name) "Load the foreign library NAME." - (sys::load-object-file name)) + (or (sys::load-object-file name) + t))
Hmm, that way %LOAD-FOREIGN-LIBRARY will never return NIL, even when loading the library really fails. We should be detecting if the foreign library is already loaded, and we should probably keep track check this new patch
of this in the portable side of things. That's needed for I'm not sure this can be done reliably, imagine for instance that someone may load libraries in their initialization file *before* loading cffi which would lead to incongruities between the lisp implementation and cffi; we should see first how many of the supported implementations have a means to see which foreign libraries have been loaded. on CMUCL there's SYS::*GLOBAL-TABLE*, on SBCL there's SB-ALIEN::*SHARED-OBJECTS* but I don't know about the others
Here's a pointer to information about loading foreign code in Allegro: http://www.franz.com/support/documentation/8.0/doc/foreign-functions.htm#loa... Looks like you might want list-all-foreign libraries in ACL: http://www.franz.com/support/documentation/8.0/doc/operators/ff/list-all-for... I hope this helps. I'm sorry, I'm not in the position to do this myself right now. But if you need test support, I could probably squeeze that in. Best, Robert
UNLOAD-FOREIGN-LIBRARY too, it's in the TODO list I think.
You're welcome to tackle that TODO item. :-) I'll see what I can do
------------------------------------------------------------------------
--- old-cffi/src/cffi-cmucl.lisp 2006-12-08 14:34:28.000000000 +0100 +++ new-cffi/src/cffi-cmucl.lisp 2006-12-08 14:34:28.000000000 +0100 @@ -341,13 +341,33 @@
(defun %load-foreign-library (name) "Load the foreign library NAME." - (sys::load-object-file name)) + + ;; one some platforms SYS::LOAD-OBJECT-FILE signals an error when + ;; loading fails, but on others(Linux for instance) it returns + ;; two values: NIL and an error string + (handler-case + (multiple-value-bind (ret message) + (sys::load-object-file name) + (cond + ;; loading failed + ((stringp message) nil) + ;; the library was already loaded + ((null ret) (values (rassoc name sys::*global-table* + :test #'string=) + :already-loaded)) + ;; the library has been loaded, but since SYS::LOAD-OBJECT-FILE + ;; returns an alist of *all* loaded libraries along with their addresses + ;; we return only the handler associated with the library just loaded + (t (rassoc name ret :test #'string=)))) + (error (err) + (declare (ignore err)) + nil)))
;;; XXX: doesn't work on Darwin; does not check for errors. I suppose we'd ;;; want something like SBCL's dlclose-or-lose in foreign-load.lisp:66 (defun %close-foreign-library (name) "Closes the foreign library NAME." - (let ((lib (find name sys::*global-table* :key #'cdr :test #'string=))) + (let ((lib (rassoc name sys::*global-table* :test #'string=))) (sys::dlclose (car lib)) (setf (car lib) (sys:int-sap 0))))
------------------------------------------------------------------------
_______________________________________________ cffi-devel mailing list cffi-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
-- Robert P. Goldman Senior Scientist Smart Information Flow Technologies (d/b/a SIFT, LLC) 211 N. First St., Suite 300 Minneapolis, MN 55401 Voice: (612) 384-3454 Email: rpgoldman@SIFT.info
On Fri, Dec 08, 2006 at 02:52:08PM +0100, Stelian Ionescu wrote:
On Fri, Dec 08, 2006 at 09:09:38AM +0000, Luís Oliveira wrote:
On 12/6/06, Stelian Ionescu <stelian.ionescu-zeus@poste.it> wrote:
(defun %load-foreign-library (name) "Load the foreign library NAME." - (sys::load-object-file name)) + (or (sys::load-object-file name) + t))
Hmm, that way %LOAD-FOREIGN-LIBRARY will never return NIL, even when loading the library really fails. We should be detecting if the foreign library is already loaded, and we should probably keep track check this new patch any comment on this patch ?
-- (sign :name "Stelian Ionescu" :aka "fe[nl]ix" :quote "Quidquid latine dictum sit, altum sonatur.")
[I'm sorry for the late reply, I've been abroad without Internet access last week.] On 12/8/06, Stelian Ionescu <stelian.ionescu-zeus@poste.it> wrote:
check this new patch
I've applied your patch with a little cosmetic changes because it's much better than the current situation. At some point, though, we should define what behaviour we want and implement it (perhaps in the portable side of CFFI) uniformly across al Lisps. Thanks! -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/
participants (3)
-
Luís Oliveira -
Robert P. Goldman -
Stelian Ionescu