[Openmcl-devel] Debian packaging for CCL

[Faheem Mitha]

Hi Gary,

Thanks for the reply. Sorry for the slow response.

On Mon, 2 Jul 2012, Gary Byers wrote:

> <https://bugzilla.redhat.com/show_bug.cgi?id=562226>  seems to describe some
> of the history of that effort.

Yikes, I get the feeling I might be out of my depth here.

I can't access any of the uploaded spec or src rpm files, so this
report is not very useful directly.

>> I'm currently seeing a rebuild failure on trunk from a clean
>> checkout. I've been able to reproduce it a few times. See
>> below. Maybe I'm doing something wrong. If so,
>> clarifications/corrections would be appreciated. However, the same
>> producedure works for me for the 1.8 release.

> You may have the environment variable CCL_DEFAULT_DIRECTORY set to
> some directory other than the directory you're trying to build in.

No, that was not the problem. It turns out the problem was that I had
a partial checkout. The level-0 and level-1 directories were missing
from the trunk checkout. Sorry, my internet connection is
super-flakey, and if svn gave a warning, I didn't see it. That is why
I like modern DVCS's like hg and git. They have better integrity in
cases like this. The trunk rebuilds Ok now.

>> It seems the only files that change in this rebuild are lx86cl and
>> lx86cl.image, correct? This is with Debian squeeze, 32 bit.

> FASL files (*.lx32fsl), .o files, and a bootstrapping image
> (x86-boot32) are also (re-)created.

Hmm. I see. Some of that is in bin, but svn doesn't seem to know about
that directory. Maybe I can use mercurial to track the changes.

>> A second, related question. It seems the lx86cl.image is the heap
>> image, and has everything loaded into it. I was wondering what
>> other files from the installation are needed. It seems something
>> else is. I did the following little experiment. I copied lx86cl and
>> lx86cl.image to /tmp. Now these files have no knowledge about the
>> rest of the installation. Then I ran 'rlwrap ./lx86cl'. I get the
>> following error.

>> faheem at orwell:/tmp$ rlwrap ./lx86cl
>>> Error: Unbound variable: CCL::FASL-VERSION
>>> While executing: ASDF::LISP-VERSION-STRING, in process listener(1).
>>> Type :GO to continue, :POP to abort, :R for a list of available
>> restarts.
>>> If continued: Skip loading init file.
>>> Type :? for other options.
>> 1 >

> You might want to look at your init file (which may be doing
> (REQUIRE "ASDF")) as well as whatever's setting
> CCL_DEFAULT_DIRECTORY (and therefore causing REQUIRE to look in the
> wrong CCL directory and find an older, incompatible version of ASDF.

The only init file I have was installed by quicklisp. This is
.ccl-init.lisp

It has the following:

##########################################################
;;; The following lines added by ql:add-to-init-file:
#-quicklisp
(let ((quicklisp-init (merge-pathnames "quicklisp/setup.lisp"
(user-homedir-pathname))))
   (when (probe-file quicklisp-init)
     (load quicklisp-init)))
##########################################################

If I move this out of the way, then I don't get an error for the /tmp
files.

To recap, I copied lx86cl and lx86cl.image into /tmp. If I run lx86cl
in /tmp vs in the source repository. I get quite different behavior
when starting and trying to load an external library using (require
'cl-rmath), depending whether or not I have moved the .ccl-init.lisp
file out of the way.

CASE 1: With .ccl-init.lisp in place

The files in /tmp give Error: Unbound variable: CCL::FASL-VERSION when
starting up lx86cl.

The source repository does not give an error when starting, succeeds
in loading (require 'cl-rmath), and runs some example code correctly.

CASE 2: With .ccl-init.lisp disabled

The files in /tmp don't give an error when starting up lx86cl.
However, loading (require 'cl-rmath) fails with

? (require 'cl-rmath)
> Error: Module CL-RMATH was not provided by any function on *MODULE-PROVIDER-FUNCTIONS*.
> While executing: REQUIRE, in process listener(1).

The source repository behaves in exactly the same way. So, there is no
difference in this case.

This suggests that the lx86cl/lx86cl.image located in the source
directory is accessing information not available to the version in
/tmp, but I don't know what that is.

If I understood why this behavior happens, I think I would have a
better understanding of the loading mechanisms involved.

>> So my question is, what other files are required for the
>> installation to work correctly, and why? The wrapper script exports
>> CCL_DEFAULT_DIRECTORY, but that does not tell me much.

> The manual will hopefully tell you more; reading it is strongly suggested.

Well, I've been reading the manual, of course. The sections on
building the system seem the most relevant. If there is a more
relevant part of the manual, then I missed it.

The section "Building the Heap Image"
(http://ccl.clozure.com/manual/chapter3.6.html#Building-the-heap-image)
seems to suggest that the full heap image contains the entire
implementation.

For example,

"When you invoke Clozure CL with the bootstrapping image, it starts
up, loads all of the Clozure CL fasl files, and saves out a new full
heap image."

However, my experiment above suggests that whether or not this is the
case, the implementation looks at the source directory for something.
Also, if the image file was standalone, then CCL_DEFAULT_DIRECTORY
would be unnecessary. Clarifications appreciated.

                                                      Regards, Faheem