Sam,
I'm going to push that off on CFFI. I think I am opening and using the GSL libraries the CFFI-approved way, so it seems that CFFI is doing something CLISP-wrong. And yes, you do have to load the cblas library before the main GSL library. The way the dependency is specified is simply by loading them in the right order.
On a related issue, I previously noticed multiple test failures in running gsll-tests in CLISP. I'm not knowledgeable enough to identify the source, but as I recall, they were of only one or two types and related to the foreign calls. Perhaps with your expertise you can run the tests and give some insight on the solution?
Unfortunately I tried to repeat the tests now and got a new error I've not seen before. In compiling conditions.lisp, there is an error *** - EVAL: variable +EDOM+ has no value This should be defined by the form at the top of the file, #.(cons 'progn (loop for i from (cffi:foreign-enum-value 'gsl-errorno :continue) to (cffi:foreign-enum-value 'gsl-errorno :eof) for name = (string (cffi:foreign-enum-keyword 'gsl-errorno i)) collect `(defconstant ,(intern (format nil "+~:@(~a~)+" name) :gsll) ,i))) which expands to (PROGN (DEFCONSTANT +CONTINUE+ -2) (DEFCONSTANT +FAILURE+ -1) (DEFCONSTANT +SUCCESS+ 0) (DEFCONSTANT +EDOM+ 1) (DEFCONSTANT +ERANGE+ 2) (DEFCONSTANT +EFAULT+ 3) (DEFCONSTANT +EINVAL+ 4) (DEFCONSTANT +EFAILED+ 5) (DEFCONSTANT +EFACTOR+ 6) (DEFCONSTANT +ESANITY+ 7) (DEFCONSTANT +ENOMEM+ 8) (DEFCONSTANT +EBADFUNC+ 9) (DEFCONSTANT +ERUNAWAY+ 10) (DEFCONSTANT +EMAXITER+ 11) (DEFCONSTANT +EZERODIV+ 12) (DEFCONSTANT +EBADTOL+ 13) (DEFCONSTANT +ETOL+ 14) (DEFCONSTANT +EUNDRFLW+ 15) (DEFCONSTANT +EOVRFLW+ 16) (DEFCONSTANT +ELOSS+ 17) (DEFCONSTANT +EROUND+ 18) (DEFCONSTANT +EBADLEN+ 19) (DEFCONSTANT +ENOTSQR+ 20) (DEFCONSTANT +ESING+ 21) (DEFCONSTANT +EDIVERGE+ 22) (DEFCONSTANT +EUNSUP+ 23) (DEFCONSTANT +EUNIMPL+ 24) (DEFCONSTANT +ECACHE+ 25) (DEFCONSTANT +ETABLE+ 26) (DEFCONSTANT +ENOPROG+ 27) (DEFCONSTANT +ENOPROGJ+ 28) (DEFCONSTANT +ETOLF+ 29) (DEFCONSTANT +ETOLX+ 30) (DEFCONSTANT +ETOLG+ 31) (DEFCONSTANT +EOF+ 32)) Shouldn't that be enough to define +EDOM+? Sorry to throw more bugs back at you, but I figure you know the most about CLISP and I know very little. Thanks.
Liam
On Thu, Aug 20, 2009 at 12:01 PM, Sam Steingoldsds@gnu.org wrote:
Hi,
I do this:
$ clisp -x '(asdf:operate 'asdf:load-op :gsll) (saveinitmem "gsll" :executable t)' $ ./gsll > > (gsll:make-chebyshev 1) FFI::FOREIGN-CALL-OUT: no dynamic object named "gsl_cheb_alloc" in library :DEFAULT
this indicates a bug somewhere between cffi and gsll. specifically, the definition of the foreign function gsl_cheb_alloc should specify that it is to be found in "libgsl.so", not in :default.
moreover, when I do the (not so) trivial thing:
(ffi:default-foreign-language :stdc) (ffi:open-foreign-library "libgslcblas.so") (ffi:def-call-out gsl_cheb_alloc (:library "libgsl.so") (:arguments (n ffi:int)) (:return-type ffi:c-pointer)) (gsl_cheb_alloc 10) ;; ==> #<FOREIGN-ADDRESS #x0000000005503380> (saveinitmem "foo" :executable t) (quit)
./foo (ffi:open-foreign-library "libgslcblas.so") (gsl_cheb_alloc 10) #<FOREIGN-ADDRESS #x0000000001D9F4C0>
i.e., if the foreign function definition includes the correct library name, the function will work automatically[*] even in the saved image.
So, since I am not quite sure where the bug is hiding, I am reporting this to both gsll and cffi lists.
Thanks. Sam.
[*] apparently, libgsl.so cannot be loaded before libgslcblas.so is. how do people specify such dependencies?!
Gsll-devel mailing list Gsll-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel