[elephant-devel] ClozureCL Intel 64 bit problem

[R. Matthew Emerson]

wkerr at cs.arizona.edu (Wesley Kerr) writes:

> I've been reading through the archives and back in June Patrick had a
> problem installing onto a 64 bit PPC machine with ClozureCL.  At one
> point he was getting some errors that looked similar to this:
>
> Undefined function #:G6340 called with arguments (#<A Foreign Pointer
> #x804E00> #<A Null Foreign Pointer> #<A Foreign Pointer #x112C70> 2 10
> #<A Foreign Pointer #x112C80> 0 10 0 #<A Foreign Pointer
> [stack-allocated] #xB0502E60> ..)  [Condition of type
> CCL::UNDEFINED-FUNCTION-CALL]
>
> Ian mentioned that he would contact the developers of ClozureCL and
> see if they could help debug the problem since it was unclear what was
> causing it.  I'm now getting these errors on a 64bit intel and I'm not
> sure where to even begin.

Ian forwarded your note to me.

At the top of src/db-bdb/berkeley-db.lisp is a declaim form that
declaims a bunch of functions inline.

(declaim 
 #-elephant-without-optimize (optimize (speed 3) (safety 1) (debug 1) (space 1))
 #-lispworks
 (inline %db-get-key-buffered db-get-key-buffered 
		 %db-get-buffered db-get-buffered db-get 
		 %db-put-buffered db-put-buffered 
                 ...))

Make that #-lispworks be #-(or lispworks ccl) and that should get you
going.

Long explanation:

Consider the following DEF-FUNCTION form:

(def-function ("db_get_raw" %db-get-key-buffered)
    ((db :pointer-void)
     (txn :pointer-void)
     ...
     (result-size :unsigned-int :out))
  :returning :int)

This macroexpands into something like

(progn
  (defun #:G0 (arg0 arg1 ...)
    ...)
  (defun %db-get-key-buffered ()
    (values (#:G0 arg0 arg1 ...)
            ...)))

If %DB-GET-KEY-BUFFERED is declaimed INLINE, we save its lambda
expression, which includes the gensym.  When the lambda expression in
substituted into a caller defined in some other file, it won't be
referencing the same #:G0, and you get undefined function error.

(Inlining across files used to be disabled, at least until several months
ago, so if this cropped up recently, that might be why.)

[from Gary Byers:]

SBCL seems to handle a toplevel (DECLAIM (INLINE FOO)) (or the combination
of the declamation and a subsequent DEFUN) as something like:

(eval-when (:compile-toplevel)
  (save-lambda-definition (lambda-definition-for 'foo) *env*))
(eval-when (:load-toplevel)
  (save-global-lambda-definition (preprocessed-definition-for foo)))

where the "preprocessed definition" appears to be fully macroexpanded
(doesn't contain references to macros that may have been defined at
compile time but might not be defined at load time.)  That could be nice
functionality to have, but there's no way that the load-time
inline-expansion and the compile-time inline-expansion can be equivalent
when uninterned symbols are involved.  Once we've crossed a point where
we can't guarantee that, I think that we're pretty much into an area
where code is depending on non-portable implementation artifacts.

Hope this helps.