Problem with foreign def-c-call-in functions in non-user packages

[Leigh Smith <leigh@antechinus.cs.uwa.oz.au>]

I've struck a snag using the latest Clisp-1995-08-12 under NeXTStep 3.3  
(Intel) calling Lisp functions from C.

Using the following C code:
% cat mycall.c

void ccall(int first, int second)
{
        void C_RETURN_FUNCTION(int msg, int tim);
        C_RETURN_FUNCTION(second, first);
}

And the corresponding Lisp:
% cat myfor.lisp
(in-package "MY-PACKAGE" :use '("LISP" "FFI"))

;(use-package "FFI")

(def-c-call-in my-c-return
  (:name "C_RETURN_FUNCTION")
  (:arguments (first int) (second int))
  (:return-type nil))

(defun my-c-return (first second)
  (format t "In my-c-return first is ~A, second is ~A" first second)
)

;(in-package "MY-PACKAGE" :use '("LISP" "FFI"))

(def-c-call-out ccall
  (:name "ccall")
  (:arguments (first int) (second int))
  (:return-type nil))

Compiling and building as per ex4 in foreign.txt produces:

+ cc -O -traditional-cpp -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit  
-Wreturn-type -fomit-frame-pointer -O2 -DDYNAMIC_FFI -Iintl  
-DLOCALEDIR="/usr/local/share/locale" modules.o myfor.o mycall.o lisp.a  
libreadline.a libintl.a libnlsut.a libavcall.a libvacall.a libtrampoline.a  
-ltermcap -o lisp.run
+ [ -n  ]
to_load=
+ [ -n  ]
+ base+mycall/lisp.run -M base/lispinit.mem -q -i -x (saveinitmem  
"base+mycall/lispinit.mem")

*** - The value of *TERMINAL-IO* was not a stream: #<CLOSED  
TERMINAL-STREAM>. It has been changed to #<TERMINAL-STREAM>.


Compiling and linking with myfor.lisp modified to have the ccall function  
in the :my-package package and the my-c-return function in the user package,  
the code works ok:

% base+mycall/lisp.run -M base+mycall/lispinit.mem -i myfor -q
;; Loading file /leigh/SysDev/clisp-1995-08-12/src/myfor.fas ...
;; Loading of file /leigh/SysDev/clisp-1995-08-12/src/myfor.fas is finished.
> (in-package :my-package)
#<PACKAGE MY-PACKAGE>
> (ccall 67 89)
In my-c-return first is 89, second is 67

>

Can someone running another Unix version of Clisp verify if this is a NS  
only bug, or have I mis-understood, and there is a requirement of all C  
callable functions to be in the user package?

Many Thanks
---
Leigh Smith            Computer Science, University of Western Australia
                       +61-9-380-1945 leigh@cs.uwa.edu.au (NeXTMail/MIME)
"In a world where success means gaining time, thinking has a single but
 irredeemable fault: it's a waste of time" - Jean-Francois Lyotard